ulf-d@obelix.UUCP (06/25/86)
I am myself a kind of Forth fan. I implemented a version of Forth on
a small Swedish micro and during that work I got to understand some
of the major problems with Forth.
First one asks oneself if Forth has an interactive environment or not.
When developing programs you can easily try the just-gonna-see-if-it-works
method. Define a new word, test it, redefine it, forget it all.
But when it comes to editing you have a problem. You don't "decompile"
a definition just like that. You can't "really" replace an old definition.
You are forced to work with a disk-based editor and with "screens".
I tried to construct a prettyprint function that should be able to
recognize BEGIN-UNTIL, IF-ELSE-THEN, BEGIN-WHILE-REPEAT etc. That's hard,
but it can be done. The problem is that all these structures can't be
found in the code, just a bunch of BRANCHs and 0BRANCHs (conditional and
non-conditional jumps).
What to do? If you impose strict rules such that all definitions can be
printed you would probably loose the "freedom of Forth". A solution could
be to define a printing function for every definition (which could be the
same for most words). But this would maybe conflict with another goal:
that of having compact code.
Another odd thing about Forth is the notion of screens. Why screens? In
my own implementation of Forth I used ordinary text files, which could
be produced by some text editor. Screens use up disk space, they are
a problem when transferring programs.
Any comments to my thoughts are welcome.
-------------------------------------------------------------------------
Ulf Dahle'n Dept of Computer Science, University of Linkoping, Sweden
email: ... enea!liuida!obelix!ulf-d
or ulf-d@obelix.UUCP
mail: Bjornkarrsgatan 15A:22, S-58248 LINKOPING, SWEDEN
phone: 46 13 176291 or 46 13 171903 or 46 431 72604
"The beginning is a very delicate time. Know then that it is the year
10191... In this time the most precious substance in the universe is the
spice Melange. The Spice extends life. The Spice expands consciousness.
The Spice is vital to space travel... Oh yes, I forgot to tell you: the
Spice exists on only one planet in the entire universe... The planet is
Arrakis, also known as Dune."
-------------------------------------------------------------------------philm@astroatc.UUCP (Phil Mason) (06/26/86)
In article <142@obelix.UUCP> ulf-d@obelix.UUCP (Ulf Dahle'n) writes: > >First one asks oneself if Forth has an interactive environment or not. >When developing programs you can easily try the just-gonna-see-if-it-works >method. Define a new word, test it, redefine it, forget it all. . . Well . . . strictly speaking I would say that Forth is interactive since you can "forget" groups of words and then type them in again. There isn't an edit-compile-debug cycle unless you use screens exclusively. It is true that you can't change just one word in a group of words unless that word is on the top of the directory. >[Decompiler question]. . .The problem is that all these structures can't be >found in the code, just a bunch of BRANCHs and 0BRANCHs (conditional and >non-conditional jumps). >What to do? If you impose strict rules such that all definitions can be >printed you would probably loose the "freedom of Forth". A solution could >be to define a printing function for every definition (which could be the >same for most words). But this would maybe conflict with another goal: >that of having compact code. The Laxen-Perry F83 decompiler is a reasonable start. It is possible to recreate the source code to an almost complete copy of the original if you have a smart decompiler. Having a special source dump part of each word would probably be overkill. >. . . But when it comes to editing you have a problem. You don't "decompile" >a definition just like that. You can't "really" replace an old definition. >You are forced to work with a disk-based editor and with "screens". You can use screens to your advantage. They break up an application into easily debugged units. If you arrange them properly, you can load only those screens that you wish to test. "Thinking Forth" by Leo Brodie has some good thoughts about screens. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Kirk : Bones ? | Phil Mason, Astronautics Technical Center Bones : He's dead Jim. | Madison, Wisconsin - "Eat Cheese or Die!" - - - - - - - - - - - - - - - -| ...seismo-uwvax-astroatc!philm | I would really like to believe that my ...ihnp4-nicmad/ | employer shares all my opinions, but . . . =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
rb@cci632.UUCP (Rex Ballard) (07/02/86)
In article <142@obelix.UUCP> ulf-d@obelix.UUCP (Ulf Dahle'n) writes: >I am myself a kind of Forth fan. I implemented a version of Forth on >a small Swedish micro and during that work I got to understand some >of the major problems with Forth. > >First one asks oneself if Forth has an interactive environment or not. >When developing programs you can easily try the just-gonna-see-if-it-works >method. Define a new word, test it, redefine it, forget it all. One version I worked with had a customized feature where the TIB was sent to a buffer, but only definitions were sent. Also, "forget" came in a second flavor which would cause the buffer definition to be forgotten too. When you had a definition you liked. You could save it to a screen for commenting and editing. As I recall, this feature required about 4 screens of packed forth. It's been about six years since I've used it, but it wasn't too hard to do. >But when it comes to editing you have a problem. You don't "decompile" >a definition just like that. You can't "really" replace an old definition. >You are forced to work with a disk-based editor and with "screens". >I tried to construct a prettyprint function that should be able to >recognize BEGIN-UNTIL, IF-ELSE-THEN, BEGIN-WHILE-REPEAT etc. That's hard, >but it can be done. The problem is that all these structures can't be >found in the code, just a bunch of BRANCHs and 0BRANCHs (conditional and >non-conditional jumps). Again, in a customized version, the token names were preserved, with the Branches and 0branches replaced by their source equivilents. Except for a few special cases, it was not too difficult to get real source back. >Another odd thing about Forth is the notion of screens. Why screens? In >my own implementation of Forth I used ordinary text files, which could >be produced by some text editor. Screens use up disk space, they are >a problem when transferring programs. Screens were originally used so that forth could be run from cassette tapes (in fact some forths still do work with tapes). It can be quite trivial to create indexed screens, or use normal files. Many forth programmers actually prefer the "screens", but don't insist that a screen be exactly 1024 bytes, space filled. Many forth installations have real editors written in forth, that can use newline terminated files. The main trick is to replace the lexical "space only" parser with a "white space" parser. It is unfortunate, but true, that many of the cures to the disadvantages of forth exist, but are proprietary, seldom sold or published, and are looked on by "forth purists" as "another language". When the '83 standard was being written, one of the big issues was whether STLs and DTLs were "really forth". In fact, many companies sold "forth-like" STLs which were compatible, but not "true '79". Many purists in the bunch wanted "100% compatibility", at the other extreme, many wanted only the "fig primitives" and "if it looks like forth it is forth". The '83 standard basicly specified standard kernal, and standard extensions. Certain definitions like CFA, NFA, and PFA had to be defined, but could be implemented any way desired, so long as it appeared to give the same result. The politics of the '83 commitee says a lot about the forces behind the language, and the future of the language. Look through the various proceedings, look at the byproducts that have been based on forth, but are not even "standard extensions". Things like parameter passing, automatic variables, static variables, heirarchal organization, classes, and typing have been done, but are often only used in "other languages", many of which still have a forth kernal at their heart.