Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uunet!world!dcp From: dcp@world.std.com (David C. Petty) Newsgroups: comp.lang.forth Subject: Re: ANS Forth Keywords: ANS Forth Message-ID: <1991Jan15.041300.14326@world.std.com> Date: 15 Jan 91 04:13:00 GMT References: <15126@sdcc6.ucsd.edu> <9101102147.AA13938@ucbvax.Berkeley.EDU> Reply-To: dcp@world (David C. Petty) Organization: The World @ Software Tool & Die Lines: 211 In article <15126@sdcc6.ucsd.edu>, ir230@sdcc6.ucsd.edu (john wavrik) writes: ``Eaker's CASE statement OCCUPIES ONE SCREEN OF CODE. Anyone who has ``liked it and wanted in their system has been able to add it and use it ``-- so the fact that it has not been part of Forth Standards is hardly In article <9101102147.AA13938@ucbvax.Berkeley.EDU>, wmb@MITCH.ENG.SUN.COM (Mitch Bradley) writes: ``> >-- so the fact that it has not been part of Forth Standards is hardly ``> >evidence of the sluggishness and perversity of the Forth community -- ``> >but is, rather, evidence that previous Standards teams have understood ``> >the nature of Forth. `` ``> Oh, oh, oh! That surely is beautifully written, especially the final ``> phrase! `` ``Beautifully written, perhaps, but irrelevant. `` ``The "nature of Forth" is an abstract thing that is largely a matter of ``one's personal set of programming values. Some people appear to be ``trying to use it as a decision criteria. As such, it is pretty useless, ``because it is so imprecise and so subjective. Au contraire... The ``nature of Forth'' is indeed relevant to the X3J14 deliberative _process_, because it is the of nature of the beast that X3J14 is attempting to wrestle to the ground. I do not think that the current members of X3J14 do not understand the nature of Forth -- they have just failed to let that understanding form the basis of their _decision criteria_. =*= Let's take the example of control structures. X3J14 might have said: ``OK we want a perfectly general and complete standard that allows users to define whatever control structures they want, so (referring to BASIS14 section B.3 pp. 158-9, Wil Baden's dissertation on Control Flow) we will define their compile time behavior as: BEGIN ( -- dest ) dest to be resolved by UNTIL and AGAIN THEN ( orig -- ) resolves orig left by IF and WHEN IF ( -- orig ) conditional branch forward from orig UNTIL ( dest -- ) conditional branch back to dest WHEN ( -- orig ) unconditional branch forward from orig AGAIN ( dest -- ) unconditional branch back to dest [NOTE: WHEN is my general factoring of ELSE; see below] DO ( -- dest ) dest to be resolved by +LOOP or LOOP LEAVE ( -- ) leave information to be resolved by +LOOP and LOOP LOOP ( dest -- ) loop back to dest, resolving any LEAVEs +LOOP ( dest -- ) loop back to dest, resolving any LEAVEs [NOTE: UNLOOP has no compile time behavior] BUT ( orig1|dest1 orig2|dest2 -- orig2|dest2 orig1|dest1 ) orig|dest swapper (used by ELSE, ENDOF, and WHILE) YET ( orig|dest -- orig|dest orig|dest ) orig|dest duplicator (used to resolve LEAVEs, but I'm not sure for what else) THENCE ( i*orig dest -- ) resolve any number of origs U> dest The glossary entries for some accepted control structure words (if they are even still _needed_) then become: ELSE is semantically equivalent to: : ELSE ( orig1 -- orig2 ) POSTPONE WHEN POSTPONE BUT POSTPONE THEN ; IMMEDIATE WHILE is semantically equivalent to: : WHILE ( dest -- orig dest ) POSTPONE IF POSTPONE BUT ; IMMEDIATE REPEAT is semantically equivalent to: : REPEAT ( orig dest -- ) POSTPONE AGAIN POSTPONE THEN ; IMMEDIATE This approach leaves a few issues hanging -- like whether orig and dest are the same size on the control flow stack; whether this scheme meets everyone's compiler security needs; what to do about ?DO, FOR, and NEXT; which words should be in the Core Word Set and which should be in the Core Extension Word Set (or a Control Flow Word Set) -- but it allows users to _portably_ `roll their own' control structures, like case statements: : CASE ( -- dest ) ( a la Eaker ) POSTPONE BEGIN ; IMMEDIATE : OF ( i*orig dest -- i*orig dest orig ) POSTPONE OVER POSTPONE = POSTPONE IF POSTPONE DROP ; IMMEDIATE : ENDOF ( i*orig dest orig1 -- i*orig orig2 dest ) POSTPONE ELSE POSTPONE BUT ; IMMEDIATE : ENDCASE ( i*orig dest -- ) POSTPONE DROP POSTPONE THENCE ; IMMEDIATE'' =*= The _other_ approach that X3J14 might have taken is to say: ``OK, we'll standardize what we _know_ everyone expects (is accepted practice) in the Core Word Set (+LOOP, AGAIN, BEGIN, DO, ELSE, IF, LEAVE, LOOP, THEN, REPEAT, UNTIL, WHILE) -- though WHILE will have a specification that requires an implementation change by many system implementors to comply with the now standard `multiple WHILE' feature (but it does not break existing code). We'll factor LOOP (and +LOOP) and throw a new word into the Core Word Set (UNLOOP) that names a function that has always existed in Forth (but has not had an accepted name until recently), because it gives us the nice behavior of allowing WHILE ... THEN to be used with a do-loop `for free.' Then we'll put a bunch of other stuff that we know about and think would be nice to have (?DO, CASE, ENDCASE, ENDOF, FOR, NEXT, OF) into the Core Extension Word Set.'' =*= I believe that the latter case is close to what has actually happened (over time and through compromise) with BASIS14. My question is, what vaunted ``decision criteria'' were applied to the control flow words of BASIS14? On one hand, accepted practice seems to be an important decision criterion (trading BUT, THENCE, WHEN, and YET for CASE, ENDCASE, ENDOF, and OF). On another hand, usefulness and completeness seem to have overruled accepted practice in the case of multiple WHILEs and the new word UNLOOP. But neither is completeness the main decision criterion, for the current BASIS has no provision for an unconditional forward branch (WHEN) and it standardizes only one form of case statement. Another decision criterion is minimizing system implementor pain, but that has been overruled by the let's-make-Forth-better criterion in the case of multiple WHILEs. But can it truly be said that the currently standardized control structures make Forth ``better'' when, with BUT, users could implement their own preferred form of WHILE and REPEAT? I realize that the control structure words were arrived at through compromise over three years and that one decision criterion that has not been compromised is the commendable and overriding desire for code portability (something X3J14 has thus far been _much_ more successful with than was the Forth Standards Team), but it appears to me that the _other_ decision criteria have become a muddle of inconsistently applied arguments. As I said above, I believe that X3J14 has failed to form coherent decision criteria based upon their understanding of the nature of Forth. John Wavrik implies that a standard Forth based on such an understanding will provide building blocks from which users can derive the greatest flexibility, but at the same time will place as few restrictions as possible on their use. With that approach X3J14 would have: standardized +LOOP, AGAIN, BEGIN, BUT, DO, IF, LEAVE, LOOP, THEN, THENCE, UNLOOP, UNTIL, WHEN, and (possibly) YET; left ?DO, FOR, and NEXT in an extension word set (though ?DO has problems); provided rationale (or implementors) notes for the default standard behavior of ELSE, WHILE, and REPEAT; and provided implementors notes for sample case statements. BASIS would thus be reduced by three words and the ultimate decisions on how control structures are used would be left to the users. In article <15126@sdcc6.ucsd.edu>, ir230@sdcc6.ucsd.edu (john wavrik) writes: ``Petty's statement: `` ``> It ``> is only necessary that standard Forth provide the facilities for ``> extending itself, so that users (and vendors) can add any language ``> extension they want. `` ``It is not clear that the ANSI team believes this. <...stuff...> ``Instead it seems that members of the Forth community are being asked ``(or dragged) to accept some high level features that many people don't ``want -- and, in return, are being expected to give up certain low ``level capabilities and simplicity which they regard as essential ``qualities of Forth. `` ``Mitch Bradley (member of ANSI team) writes, `` ``> If everything goes well, ANS Forth will drag the Forth community ``> kicking and screaming into the late '70's. I don't believe X3J14 will actually change the current BASIS (and I am not writing any proposals to the effect that they do). The purpose of my discussion is to point out what, in my heretical opinion, is a major problem with the X3J14 deliberative process -- the lack of clearly articulated decision criteria. It has been my experience that the decision criteria of accepted practice, code portability, ``[indispensability] to the production of a coherent standard'' (see BASIS 14, _Preface: Scope of Work for X3J14_, between pp. viii and ix), dragging Forth ``...kicking and screaming into the late '70s'' (whether the added features are gotten ``for free'' or not), fixing bugs, compromise with existing standards (God forbid!), and others, have all been used to justify the inclusion or exclusion of any word or concept whatsoever, depending on the whim of the person presenting the argument! I have seen people use certain decision criteria to argue both for and against an idea (though not usually in the discussion of a single proposal). In short, I do not believe that X3J14 has a firm and consistent grasp on the nature of the process of standardizing Forth. In article <9101102147.AA13938@ucbvax.Berkeley.EDU>, wmb@MITCH.ENG.SUN.COM (Mitch Bradley) writes: ``Forth must adapt to the new "climate" or die. On this, I agree with Brad Rodriquez that the ends do _not_ justify the means, but (mercifully) _that_ is a topic for another message. -- David C. Petty | dcp@world.std.com | ...!{uunet,bu.edu}!world!dcp /\ POBox Two | CIS: 73607,1646 | BIX, Delphi, MCIMail: dcp / \ Cambridge, MA | `It must've been some-other-body, / \ 02140-0001 USA | uh uh babe it wasn't me...' /______\