Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!ucsd!ucbvax!MITCH.ENG.SUN.COM!wmb From: wmb@MITCH.ENG.SUN.COM (Mitch Bradley) Newsgroups: comp.lang.forth Subject: DOER..MAKE Message-ID: <9008081745.AA29723@ucbvax.Berkeley.EDU> Date: 8 Aug 90 17:33:23 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Mitch Bradley Organization: The Internet Lines: 108 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, Mitch