ir230@sdcc6.ucsd.edu (john wavrik) (12/29/90)
CASE and ANSI Mitch Bradley writes, > Regarding Eaker's case statement, widespread is not the same as "you > can count on having it". Also, Eaker's CASE was published 12 years > ago, and ANS Forth has just now added it to the draft standard. If > it takes the Forth community 5 or 10 more years to standardize basic > language extensions like a file system interface and memory > allocation and error handling and floating point and search order > control, then I for one will be tempted to give up on the language. > If everything goes well, ANS Forth will drag the Forth community > kicking and screaming into the late '70's. David Petty (on behalf of Boston FIG) writes, > Forth is, after all, one of the few extensible languages. It is not > necessary to put every language extension into standard Forth. 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. The original code for the Eaker CASE statement is listed below. Those who have never seen the code before will find it instructive. It is written in FIG-Forth and has a slightly arcane appearance which comes primarily from the fact that Eaker integrated his code with the FIG- Forth "compiler security" scheme used to check that conditionals are properly paired. [The leading conditional of a pair puts a magic number on the stack (at compile time) which is checked by the the word ?PAIRS contained in the trailing member. BEGIN put a 1 on the stack, IF put a 2, DO put a 3. Eaker had his CASE put 4 and OF put 5.] A version of the Eaker CASE statement which will run on current systems is also included. It uses whatever compiler security the system provides for IF..ELSE..THEN -- and it includes an optional OTHERWISE clause. The third screen shows an example of usage. 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 evidence of the sluggishness and perversity of the Forth community -- but is, rather, evidence that previous Standards teams have understood the nature of Forth. Eaker's CASE statement, excellent as it is, is only one of many. It is not what one would use for a very large number of keys. It is not what one would use if the consequents were single words (rather than phrases). It is not what one would use if the keys were consecutive numbers. It is really just a syntactical improvement over the sequence of nested IF..ELSE..THEN statements it compiles -- a general purpose CASE statement suited for matching a relatively small number of numerical keys. For those who have needed a case-like statement to run as fast as possible it almost always better to write one specialized to the application using assembly language components. The ability of users to do this is just another example of those little things that make Forth Forth. Oddly enough, the lack of a CASE statement in Forth has always been one of my selling points for the language. Here's why: When I first started using Forth, Pascal was the language of choice here at UCSD. Contrary to popular belief, UCSD Pascal was not the main dialect used for research work at UCSD (it was mostly used in teaching) -- a different dialect was installed on the central computers. One of the differences between the dialects was that one (I think it was UCSD) supported an OTHERWISE clause in CASE statements while the other didn't. The effect of this was that those who used OTHERWISE in their programs had to revise their code when switching to the other dialect. Forth provides a unique solution to situations like this: Forth gives a user control over the language itself. It allows him to add whatever CASE construct he needs. He can change the language rather than the code! The real clash between the ANSI team and the Forth Community lies in 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. The real issue is whether Forth is a language to which "users (and vendors) can add any language extension they want" -- and the controversial part is about the "users" not the "vendors". The push to have certain high level features made standard may stem from the fact that users will no longer be able to add them (at least not portably). If you are interested in making your own control structures you will find that you no longer have BRANCH and ?BRANCH to work with -- but must make everything with higher level words. The latest BASIS document contains a paper by Wil Baden as an appendix showing how some complicated control structures can be built using an extended set of high level words. This is fine except for one thing: Baden's extended words do not appear in the body of the BASIS document, nor can they be built from words in the body. One may wonder if the purpose of the appendix is to fool people into believing that the proposed Standard will let them do things that they, in fact, will not be able to do. The idea of a stratified Standard, mentioned by several people in this newsgroup, is in fact the only sensible way to produce a Standard for Forth -- BUT I think the "minimalist" position is being misunderstood. A minimalist is not someone who wants just any old small set of words -- but rather *that* small set which is sufficient to build the language. If it were clear that: (1) the CORE wordset contains what is necessary to allow users to add any language extension they wish and (2) that the extended wordsets consist of extensions which can be added on as options to CORE systems then I think that there would be some possibility of consensus. 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 was originally going to comment on this. John J Wavrik jjwavrik@ucsd.edu Dept of Math C-012 Univ of Calif - San Diego La Jolla, CA 92093 Eaker's CASE Statement ===================================================================== ORIGINAL EAKER CODE 0 \ Eaker CASE statement -- Forth Dimensions vol II no 3 1 \ Sept/Oct 1980 2 3 : CASE ?COMP CSP @ !CSP 4 ; IMMEDIATE 4 5 : OF 4 ?PAIRS COMPILE OVER COMPILE = 6 COMPILE 0BRANCH HERE 0 , COMPILE DROP 5 ; IMMEDIATE 7 8 : ENDOF 5 ?PAIRS COMPILE BRANCH HERE 0 , 9 SWAP 2 [COMPILE] ENDIF 4 ; IMMEDIATE 10 11 : ENDCASE 4 ?PAIRS COMPILE DROP 12 BEGIN SP@ CSP @ = 0= WHILE 13 2 [COMPILE] ENDIF REPEAT 14 CSP ! ; IMMEDIATE 15 GENERIC VERSION OF EAKER CASE STATEMENT 0 \ Eaker CASE statement -- Generic 1 2 VARIABLE CASES 3 4 : CASE 0 CASES ! ; 5 6 : OF 1 CASES +! COMPILE OVER COMPILE = 7 [COMPILE] IF COMPILE DROP ; IMMEDIATE 8 9 : ENDOF [COMPILE] ELSE ; IMMEDIATE 10 11 : OTHERWISE COMPILE DUP ; IMMEDIATE 12 13 : ENDCASE COMPILE DROP CASES @ 0 14 DO [COMPILE] THEN LOOP ; IMMEDIATE 15 USAGE 0 \ Eaker CASE statement -- TEST 1 2 : TESTCASE CASE 3 2 OF ." It is two " ENDOF 4 3 OF ." It is three " ENDOF 5 OTHERWISE ." I don't know " . 6 ENDCASE ; 7 8