wmb@MITCH.ENG.SUN.COM (Mitch Bradley) (08/09/90)
MB>Another common technique is the DOER ... MAKE construct described in
MB>_Thinking Forth_ . Personally, I do not like DOER ... MAKE because it
MB>adds yet another non-postfix syntactic construct to Forth.
CE> I'm surprised you feel this way. The DOER...MAKE construct strikes me
CE> as being no more non-postfix than the _double_ non-postfixedness (??) of
CE> both ' and IS with DEFER.
However, a postfix version of IS is possible (and in fact is used in
a later example). A postfix version of MAKE is not possible, unless
you add some more words to create anonymous colon definitions. So,
from a theoretical standpoint, the DEFER example can be reduced to one
non-postfix construct ( ' ), and that non-postfix construct already
exists in the language and is essentially unavoidable. Some language
theoretician once proved that a language needs at least 1 "look-ahead"
construct.
Every non-postfix contruct detracts from the regularity and understandability
of the language, because non-postfix constructs behave differently in
different states. They are also difficult to decompile and difficult
to metacompile.
MAKE is particulary troublesome because it introduces yet another way
to start a colon definition. There ought to be just one way to start
a colon definition, but there are currently 2 ( : and DOES> ), and
MAKE is a third.
DOER BAR
: FOO ." Hello world" MAKE BAR ." Wucka, wucka, wucka" ;
Essentially, the stuff after "MAKE BAR" is a "colon definition inside
a colon definition". Such constructs make it difficult to write programs
to automatically analyze Forth programs, greatly complicate decompiling
and metacompiling, and make it more difficult to do object-oriented things
(where you would like to have a program automatically generate Forth code).
Similar comments apply to DOES> ; the problems with DOES> were recognized
many years ago ("A New Syntax for Defining Words" Bill Ragsdale, Forth
Dimensions, Vol.2 No.5, Jan. 1981).
> Furthermore, the DOER...MAKE construct is far more versatile
> ... avoiding the need to add BAR to the dictionary.
I don't view the avoidance of adding a name to the dictionary as a
versatility issue. It's a space issue, and that can be solved in a
much more useful way by adding the ability to make headerless words
(because then ANY word can be made headerless, not just the actions
of DEFER/DOER words).
> In addition, MAKE can be used in colon definitions of words that set
> DOER (or DEFER) variables that model, in a straight-forward way, state
> machines with actions associated with transitions
Ditto for (IS . MAKE and IS are similar in power.
> your prefered definitions of [ and ] would be slightly less ugly with the
> DOER ... MAKE construct. Instead of :
> ...
> ['] (literal? ['] literal? (is
> ['] interpret-do-defined ['] do-defined (is
> ...
> they would be:
> ...
> make literal? (literal? ;and
> make do-defined interpret-do-defined ;and
> ...
Part of the "ugliness" of the first approach is an unfortunate
choice of names. Suppose that the Forth-83 team had not botched
the ' vs. ['] thing, and that I had chosen the name SET instead
of (IS . Then the first example would be written as:
' (literal? ' literal? set
I don't think this is too ugly.
The appeal of
make literal? (literal? ;and
lies in the fact that it is sort of like English. Unfortunately,
Forth syntax isn't very much like English in any other way, so
trying to use English as a guide is not likely to be productive.
> I find MAKE FOO BAR slightly less opaque than ' FOO IS BAR
Again, this appears to be an artifact of the English language.
In my oponion, most of the technical problems with Forth arise from
places where Forth departs from its postfix heritage and attempts to
be "like English". CREATE is the prime example.
The Right Way is to have exactly one method for creating a colon
definition and a general purpose postfix method for giving something
a name. e.g.
{ HERE . } " FOO" DEF instead of : FOO HERE . ;
VAR " V1" DEF instead of VARIABLE V
5 CONSTANT " C1" DEF instead of 5 CONSTANT C1
An important test of power: The Forth Way can be defined in terms
of the Right Way, but not vice versa, e.g.
{ VAR [COMPILE] " DEF } " VARIABLE" DEF
Cheers,
Mitcheaker@sunbelt.crd.ge.com (Charles E Eaker) (08/09/90)
In article <9008081745.AA29723@ucbvax.Berkeley.EDU> Mitch Bradley <wmb%MITCH.ENG.SUN.COM@SCFVM.GSFC.NASA.GOV> writes: >Similar comments apply to DOES> ; the problems with DOES> were recognized >many years ago ("A New Syntax for Defining Words" Bill Ragsdale, Forth >Dimensions, Vol.2 No.5, Jan. 1981). Thanks for the reference. For some reason I never read this paper. It's quite good. >The appeal of > > make literal? (literal? ;and > >lies in the fact that it is sort of like English. I confess that I am (perhaps fatally) attracted to English-like Forth. What other language allows you to create an application in less than 30 seconds that lets a user step up to the keyboard and type: Total for burger fries and shake is <return> with the total immedately displayed? ( Here's how: ) : is_cost_of create , does> @ + ; : Total 0 ; : is . : : for ; : and ; 250 is_cost_of burger 100 is_cost_of fries 150 is_cost_of shake I'm not suggesting that this can't be done in the pure postfix style. This is merely an example of an English-like application that is easily created with Forth. My problem is that Forth itself is an application I use to create applications and I, like my users, prefer an English-like environment in which to get my work done. In fact, that's a conscious goal which, when achieved, feels as though I've done it The Right Way (e.g., "is_cost_of" above). On the other hand, I appreciate the value of a foundation that is simple, consistent, and regular, and I know how the traditional Forth model fills decompilers and metacompilers with ad hoc-isms that must be expanded with the addition of each new non-postfix-ism. I remain torn. Perhaps there's a cure waiting for me out there somewhere. Thanks for an excellent response. -- Chuck Eaker / P.O. Box 8, K-1 3C12 / Schenectady, NY 12301 USA eaker@sungod.crd.ge.com eaker@crdgw1.UUCP (518) 387-5964
wmb@MITCH.ENG.SUN.COM (08/10/90)
> On the other hand, I appreciate the value of a foundation that is > simple, consistent, and regular, and I know how the traditional Forth > model fills decompilers and metacompilers with ad hoc-isms that must be > expanded with the addition of each new non-postfix-ism. > > I remain torn. Perhaps there's a cure waiting for me out there somewhere. > Thanks for an excellent response. I think it is possible to "have your cake and eat it too" in this case. I have no problem with adding "syntactic sugar" *on top of* a regular postfix foundation. If the primitives are done correctly, then it is often easy to define the "syntactic sugar" in terms of the primitives. The converse is usually not true. A number of Forth constructs are defined at too high a level. FIND is one example (there should be a primitive VFIND that searches just one vocabulary). FORGET is another (the operation of unlinking words from a vocabulary should be separate from the operation of reclaiming the dictionary space). As previously stated, the operations of creating the executable object and giving it a name should be separate in defining words. Cheers, Mitch
dwp@willett.pgh.pa.us (Doug Philips) (08/10/90)
MB>Another common technique is the DOER ... MAKE construct described in
MB>_Thinking Forth_ . Personally, I do not like DOER ... MAKE because it
MB>adds yet another non-postfix syntactic construct to Forth.
CE> I'm surprised you feel this way. The DOER...MAKE construct strikes me
CE> as being no more non-postfix than the _double_ non-postfixedness (??) of
CE> both ' and IS with DEFER.
Just checked my copy of _Thinking Forth_. Most of the book is sprinkled
with quotes from various people, CM included, that support the authors
position. The section on DOER ... MAKE is prefaced with:
The traditional techniques for implementing vectored execution
are described in _Starting Forth_, Chapter Nine. In this section we'll
discuss a new syntax which I invented and which I think can be used
in many circumstances more elegantly than the traditional methods.
There are no quotes in the 6 pages he takes to describe and give examples
of his two new words. I think that that lack of quotes is significant.
In the end, I agree with Mitch on this point.
MB> Every non-postfix contruct detracts from the regularity and
MB> understandability of the language, because non-postfix constructs
MB> behave differently in different states. They are also difficult to
MB> decompile and difficult to metacompile.
This argues strongly against adding non-post-fix constructs. I don't think
it is powerful enough an argument to rule out any non-post-fix constructs.
MB> MAKE is particulary troublesome because it introduces yet another way
MB> to start a colon definition. There ought to be just one way to start
MB> a colon definition, but there are currently 2 ( : and DOES> ), and
MB> MAKE is a third.
[ . . . -dwp]
MB> Similar comments apply to DOES> ; the problems with DOES> were recognized
MB> many years ago ("A New Syntax for Defining Words" Bill Ragsdale, Forth
MB> Dimensions, Vol.2 No.5, Jan. 1981).
Ok, so I'll ask the obvious question, though it isn't really a technical
question: _Why_ hasn't Ragsdale's idea caught on? I just skimmed the
article and it made a lot of sense to me. On the other hand, I'm a novice
to Forth, so "made a lot of sense to me" could be a bad sign.
MB> lies in the fact that it is sort of like English. Unfortunately,
MB> Forth syntax isn't very much like English in any other way, so
MB> trying to use English as a guide is not likely to be productive.
Chuck Moore (as quoted by Brodie in _Thinking Forth_, page 262)
I would distinguish between reading nicely in English and
reading nicely. In other languages such as Spanish, adjectives
follow nouns. We should be independant of details like which
language we're thinking in.
It depends on your intention: simplicity, or emulation of
English. English is not such a superb language that we should
follow it slavishly.
MB> In my oponion, most of the technical problems with Forth arise from
MB> places where Forth departs from its postfix heritage and attempts to
MB> be "like English". CREATE is the prime example.
I think there is a distinction to be made here. As I understand the
simplifying power of Forth, and with simplicity in general, one *can*
take it too far. I'm inclined to agree with you here. I would like
to see a standardize kernel that is much more postfix. From that
you can build the "friendly" user stuff without making it hard to write
programs that write programs.
MB> An important test of power: The Forth Way can be defined in terms
MB> of the Right Way, but not vice versa, e.g.
I don't know that I'd want to buy into the morality of "the Right Way",
but I think the point about expressiveness and power is true.
-Doug
---
Preferred: ( dwp@willett.pgh.pa.us OR ...!{sei,pitt}!willett!dwp )
Daily: ...!{uunet,nfsun}!willett!dwp [last resort: dwp@vega.fac.cs.cmu.edu]dwp@willett.pgh.pa.us (Doug Philips) (08/10/90)
In <10887@crdgw1.crd.ge.com>, eaker@sunbelt.crd.ge.com (Charles E Eaker) writes: > I confess that I am (perhaps fatally) attracted to English-like Forth. > What other language allows you to create an application in less than 30 > seconds that lets a user step up to the keyboard and type: > > Total for burger fries and shake is <return> > > with the total immedately displayed? First, see my earlier reply to Mitch with the CM quote about "following English slavishly." I think that CM is right about that. If you do it, you're unnecessarily limitting yourself. Second, last time I check most fast food joints have special cash registers with keys for "burger" "fries", etc. Much quicker than typing whole words on keyboards, and not as linear, but definitely the same idea already done, half in hardware. > My problem is that Forth itself is an application I > use to create applications and I, like my users, prefer an English-like > environment in which to get my work done. In fact, that's a conscious > goal which, when achieved, feels as though I've done it The Right Way > (e.g., "is_cost_of" above). I'm not sure what you mean by "problem". I think CM's point about Spanish (see other message) is a good one. Noun first, then adjectives. Spanish is then more like a human version of Forth: Push item and then tweak it. -Doug --- Preferred: ( dwp@willett.pgh.pa.us OR ...!{sei,pitt}!willett!dwp ) Daily: ...!{uunet,nfsun}!willett!dwp [last resort: dwp@vega.fac.cs.cmu.edu]
eaker@sunbelt.crd.ge.com (Charles E Eaker) (08/11/90)
In article <9008101346.AA02615@ucbvax.Berkeley.EDU> wmb%MITCH.ENG.SUN.COM@SCFVM.GSFC.NASA.GOV writes: >I think it is possible to "have your cake and eat it too" in this case. >I have no problem with adding "syntactic sugar" *on top of* a regular >postfix foundation. Hmmm. Then, what, if anything, is wrong with DOER...MAKE when viewed as syntactic sugar? -- Chuck Eaker / P.O. Box 8, K-1 3C12 / Schenectady, NY 12301 USA eaker@sungod.crd.ge.com eaker@crdgw1.UUCP (518) 387-5964
wmb@MITCH.ENG.SUN.COM (Mitch Bradley) (08/11/90)
> Hmmm. Then, what, if anything, is wrong with DOER...MAKE when viewed > as syntactic sugar? The fact that no attempt has been made to describe or specify the primitives upon which it must be built. Mitch