boris@M66-080-3.mit.edu (Boris N Goldowsky) (04/13/88)
I just learned a little bit of PostScript the other day, and it seems
to be a lot like Forth in several ways. Does other people in this
newsgroup use it? From my brief experience with it it looks like
there are some things that Forth could learn from it - for example in
the way it treats data types, and the nice way that def (equivalent to
Forth's :) is a postfix operator like everything else. Anyone know more?
Boris
--
Boris Goldowsky boris@athena.mit.edu or @adam.pika.mit.edu
%athena@eddie.UUCP
@69 Chestnut St.Cambridge.MA.02139
@6983.492.(617)toma@tekgvs.TEK.COM (Tom Almy) (04/14/88)
In article <BORIS.GNUS6@M66-080-3.mit.edu> boris@M66-080-3.mit.edu (Boris N Goldowsky) writes: >I just learned a little bit of PostScript the other day, and it seems >to be a lot like Forth in several ways. [...] the nice way that def >(equivalent to Forth's :) is a postfix operator like everything else. >Anyone know more? Not only is def postfix, but also the control structures. The trick is that code sequences are simply data, so an IF function gets passed two things, a boolean value and a block of code to execute if the expression is true. A nice "Forth-like" idea that would have made Forth completely consistant; this concept is used in Lisp and Smalltalk already. PostScript memory is dynamically allocated, thus is more flexible than Forth. On the flip side, PostScript is considerably slower.
D_FELDMA@UNHH.BITNET (11/17/89)
Tom Almy's note (Re: Forth in C (was Re: Forth from scratch)) prompts me to ask the following question. Has anyone written an (approximation of) Forth in PostScript, or vice-versa. What are or would be the hardest features of each to impliment in the other. I'm a long time Forth user (MVP Forth-79 still running on my trusty Apple IIe) and lately an enthusiastic PostScript user, thought in a completely different environment. It would be pleasant to be able to use (constructs from) either language in either environment. David Feldman Department of Mathematics University of New Hampshire D_FELDMAN@UNHH.BITNET
cralle@LLL-CRG.LLNL.GOV (Bob Cralle) (11/17/89)
postscript is a subset of forth. warnock likes to play like it isn't but it is!
he brot back (), really {} to surround proceedures in definitions. thus there
are
two ways to define words the above & /word ... def. for : ... ;
healsodidn't want to be identified with a cult language such as forth so he
did cutsy things: 'exch' for 'swap'; 'pop' for 'drop'; etc etc etc.
it is ironic that the deservedly great language postscript is scurrilessly
being damaged by MS & Apple's behavior in creating yet another std. which we
don't need. Especially so given adobe in large measure made both MS &
Apple.
2-way translators r hard: the '/' no space 'word-name' make your translator
have to crack '/word' apart etc. No create-does without jumping thru
hoops... bad news all the way.
: mul * ; works for ps to forth but not vs.
these are all big problems, pity!
bob
cralle@lll-crg.llnl.govwmb@SUN.COM (11/18/89)
The PostScript interpreter is easy. The graphics libraries are the hard part. James Gosling, who wrote the PostScript interpreter in the NeWS window system, told me that he spent a week on the interpreter and over a year on the graphics libraries. That's not counting the font scaling. Sun bought a company just to get the font scaling technology (Folio). By the way, using the [: ... ;] construct that Dr. Wavrik described in a recent posting, you can easily implement PostScript-style control structures (as Tom Almy alluded to). Mitch
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (12/22/90)
Date: 12-18-90 (17:01) Number: 599 of 618
To: GARY SMITH Refer#: 491
From: DENNIS MCCUNNEY Read: NO
Subj: BASICS OF THE FORTH LANGU Status: PUBLIC MESSAGE
Conf: FORTH (58) Read Type: GENERAL (+)
GS3 >P.S. The main challenge to the Forth community is to show
GS3 that > putting more control over the language in the hands
GS3 of the > programmer can result in more power without
GS3 drastically > increasing error or increasing the incidence
GS3 of incompre- > hensible programs.
GS3
GS3 I have seen nothing so far that would enable me to distinguish
GS3 PostScript from Forth. In fact, the power and popularity of
GS3 PostScript would seem to have proved the point already.
Yes, but who writes directly in Postscript? In most cases,
applications generate Postscript code, not programmers.
-> MegaMail v2.01 #0:12/18/1990 - R/O Capable - Route to ->RUNNINGB
PCRelay:RUNNINGB -> #3 RelayNet (tm)
4.10 Running Board 2126541349/DS/2125191791/HST/
<<<>>>
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwpdaniel@nstn.ns.ca (Daniel MacKay) (12/23/90)
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) writes: > Yes, but who writes directly in Postscript? In most cases, > applications generate Postscript code, not programmers. Lots of people. Don Lancaster, published a toolkit for working in Postscript, and says (I paraphrase) "The Macintosh applications are the worst way to get drawings out of a PS printer." The toolkit consists of several disks worth of code for drawing schematics, posters, 12-up biz cards, &c. When you do work directly in Postscript, you do something very FORTH-like: you write little bits of your application, try them out, and hook them together. So halfway through my "Postscript Ruler" project (because the rulers I had, had printer's points on them, and since I was doing rather exacting work, I needed the measurement I was woring with, Postscript points (again, a very FORTHish concept- building your own tools)) I had numbers scattered over the page, all sizes of tic marks, the main ruler backbones &c. Once they were looking good, they all got connected together. When it was done, it got sent to a Linotronic for output on film at 1200dpi. -dan
wmb@MITCH.ENG.SUN.COM (Mitch Bradley) (12/24/90)
> Don Lancaster, published a toolkit for working in PostScript Anybody got a reference? Pointers for tracking down a copy? > Yes, but who writes directly in Postscript? People who write applications for the NeWS window system (available on Sun and SGI machines) and for Display PostScript (NeXT machines). Also people who write the applications that generate PostScript code. Of course, many of these people would *rather* program in C, because that is what they know best. Mitch
shri@ncst.ernet.in (H.Shrikumar) (12/27/90)
In article <9012270400.AA22108@ucbvax.Berkeley.EDU> Mitch Bradley <wmb%MITCH.ENG.SUN.COM@SCFVM.GSFC.NASA.GOV> writes: >> Yes, but who writes directly in Postscript? > >People who write applications for the NeWS window system (available on >Sun and SGI machines) and for Display PostScript (NeXT machines). Also >people who write the applications that generate PostScript code. Mitch is correct. Please remember that tho' people dont write in assembly directly as much any more has not diminished its importance. @ The view as I can see from atop my soap-box is that embedded applications @ are going to get bigger and bigger. Youd need more programmers on each @ than just one (No, I am *not* implying that many FORTH porgrammers cannot @ collaborate, please do read on.) And, more importantly, more and more @ of these embedded systems are going to be used in critical missions. @ @ Thus, we see here a window of opportunity, perhaps a few years wide, @ when embedded systems will make a sharp ascent. Surely there will be @ teething troubles and hiccups before this industry makes the steep @ ascent to $800 million (hope I am not number numb here :-). @ @ One way to avoid these is by extensive testing, another is via @ formal verification. No religion here please ... both have their place @ in a production environment. You can prove somethings best, you can @ test other things better. @ @ Such production environment would need ... well an environment, @ with tools such as SCCS/RCS or other version control systems, project @ management etc. These would be large machines, probably running a @ standard OS (maybe UNIX or other) 'cos the management trusts this @ as a production environment. @ @ But the end system, the embedded product will still be small, @ memory constrained and tightly engineered. @ @ OK so much for my view in the crystal ball. What is happening today ? @ @ Many C compilers and development systems are beginning to be available @ for micro-controllers. C gives a much cleaner semantics than assembly, @ so making production more predictable than before. This tends to @ prove the point I am making above about trends. @ @ So the developers design the entire application in one @ such environment, download/burn it (or use an ICE/MDS) and test @ out the system. @ @ If they wanted a realtime kernel, they often build one, there @ are very few standard products for tiny controllers. Read: No @ re-use of software. @ @ If you had a slightly larger than a 8051-genere system, you could @ use one of VRTX or P-SOS or other real-time kernels. But not @ always do these integrate well with your C environment of choice. @ @ Now is not Forth a language with "much cleaner semantics than @ assembly". Sure! @ @ And is Forth not much much "lighter" than C. Undoubtedly! @ @ And dont developers patch code ? More often than they'd care to @ admit. Why, when dust clogged the NASA computers recently, they had to. @ The 1801 Shuttle CPUs have been patched several times too, I believe. @ Now patching C code is tough .. you need a copy of the symbol table, @ maybe a disassembler and symbolic execution tool too. But FORTH, @ due to the price of simplicity paid up-front can be de-compiled, @ and even patched manually with little trouble, and little supporting @ software (a FORTH (de)compiler is not more than a few dozen words long). @ @ It seems to me therefore that a good environment would be one which gives @ you a langauge like ADA or OCCAM or POSIX-C (with threads) to program @ in, so you can write big code. (It is doomed to failure if we try to @ sell Forth to replace these languages in toto; after all much $$$$ has @ already gone into them). It generates code for a FORTH which supports @ a good (probably provable) hard real time kernel, with very efficient @ (tightly optimised) IPC. @ @ This Forth system runs on the embedded box, and small changes can @ be as easily patched. OK ... off my soap-box .. ... SO what does postscript teach us ? Like Mitch points out, the NeWS applications are analogous to my cross-development environment, guys who write these are writing a High-level to PostScript cross-compiler. The display of laser printer is an embedded product, which executes these. (In my case above, they store them later for repetitive execution, a small difference not significant here). You can patch PostScript code to do some small special things, as I have done several times when I did not want to wait for the UNIX machine to be booted to re-run dvi2ps for just a small change of the top-margin. Imagine if the output had been HPGL or worse still, some escape sequences ... I would have had no choice but to re-run the postscript generator. Thus, since PostScript is clean enough, other programs can generate arbitarily complex pictures (even gorgeous fractals !), and yet I can put a gsave mycode grestore and insert my cute one-liner in the middle. This is the lesson that PostScript teaches us. A simple and clean underlying system - as simple and as clean as possible. This is what Mitch says when he wants Forth to get rid of too many closures. This is what John Warvick wants when he thinks Forth can express mathemtical ideas very concisely and precisely. -- shrikumar ( shri@ncst.in ) PS: In an earlier article Mitch Bradley writes: me>[Re. config of machines for FORTH speeds] Mitch, could you clarify please ? > >Actually, I was comparing apples to apples; (all) Forths were all running >in the same environment (on a Sun workstation under Unix, with one user). BTW, Mitch, I was not making any implications, only wanted to know. I only asked because if stand-alone then cache control is in your hands, (innerinterpretter in cache, and dont ever flush it etc.) if under UNIX you will tends to get flushed once in a while, skewing the benchmarks slightly. Thanx for the clarifier. >In my experience, a good Unix implementation will not slow down a >compute-bound application by more than 2 or 3 percent. Very very true. PPS: Whew! a long one again !! PPPS: Wishing all a Happy News Year and a Great Decade !!!