a684@mindlink.UUCP (Nick Janow) (01/12/91)
ForthNet@willett.pgh.pa.us (JACK WOEHR) writes: > So true, Frank! The main thing that troubles me about adding CASE to Forth > is that there are many possible CASE constructs that are equally worthy of > the name. One that I particularly liked CASEd counted strings!, e.g. > > : FOO " this" ; > : BAR " that" ; > : ZOTZ CASE " this " OF DO-THIS ENDOF CASE " that" OF DO-THAT ... > > So adding CASE to the Standard, while gratifyingly adding the X3J14 sanction > to the form of CASE coincidentally implemented in Vesta Forth-83+, seems an > act of lese-majeste against the Forth imperative not to name something once > and for all that is a matter of personal taste and implementation strategy. If you think it's a better CASE than the one presently favoured, try to convince the others to accept it. Otherwise, if the present one is chosen for whatever reasons (in common use, simple, etc), then rename your favourite CASE to $CASE (or whatever you prefer) and add it to your programs. I'd rather see one standard--even if it's limited--CASE method instead of dozens of incompatible ones.
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (01/12/91)
Date: 01-09-91 (10:30) Number: 820 of 821 (Echo)
To: FRANK SERGEANT Refer#: 806
From: JACK WOEHR Read: NO
Subj: CASE OF CODE Status: PUBLIC MESSAGE
Conf: FORTH (58) Read Type: GENERAL (+)
-> John Wavrik wrote:
-> >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.
-> Oh, oh, oh! That surely is beautifully written, especially the final
-> phrase!
So true, Frank! The main thing that troubles me about adding
CASE to Forth is that there are many possible CASE constructs that
are equally worthy of the name. One that I particularly liked CASEd
counted strings!, e.g.
: FOO " this" ;
: BAR " that" ;
: ZOTZ CASE " this " OF DO-THIS ENDOF CASE " that" OF DO-THAT ...
So adding CASE to the Standard, while gratifyingly adding the
X3J14 sanction to the form of CASE coincidentally implemented in
Vesta Forth-83+, seems an act of lese-majeste against the Forth
imperative not to name something once and for all that is a matter
of personal taste and implementation strategy.
=jax=
NET/Mail : RCFB Golden, CO (303) 278-0364 VESTA & Denver FIG for Forth!
<<<>>>
-----
This message came from GEnie via willett. You cannot Reply to the author
using email. Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, whatever).
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwpwmb@MITCH.ENG.SUN.COM (Mitch Bradley) (01/13/91)
It doesn't seem like such a bad thing if the name "CASE" is restricted to mean just one thing; there are lots of other names that can be used for other kinds of multi-way selection data structures. How about SELECTS or SWITCH or CHOICES or SELECTOR or JUMP-TABLE: or CASE: or whatever. Heck, CASE really isn't that good of a name anyway; it just happens to be what some other language (Pascal? Algol? I forget) uses (it's not C; C uses "switch" at the top and "case" where Eaker uses "OF"). To my way of thinking, it is far worse for us as a community to adopt the attitude "let's all pick our own personal meanings for the same word". A word only has value to the extent that multiple people agree on its meaning. Vague meanings like "well it is probably some sort of selection among several alternatives, but only the author knows for sure what it does to the stack" don't cut the mustard for something as precise as computer programming. If they did, then we'd have no need for Forth because computers would be programmed in some (ambiguous, ubiquitous) natural language like English . The Forth word CASE has more value to the Forth community if ANS Forth declares it to mean Eaker's case than it has as a 4-letter identifier that you can use to mean your own private thing. I haven't run up against a shortage of unique identifiers lately, and my systems are so big that C. Moore litmus judges them to be "not worth doing" (although his latest chip finally has enough address bits to support them!). Cheese louise, why are people so jealous about a few names? The name space is huge. Mitch
jax@well.sf.ca.us (Jack J. Woehr) (01/14/91)
a684@mindlink.UUCP (Nick Janow) writes: >ForthNet@willett.pgh.pa.us (JACK WOEHR) writes: >> So adding CASE to the Standard, while gratifyingly adding the X3J14 sanction >> to the form of CASE coincidentally implemented in Vesta Forth-83+, seems an >> act of lese-majeste against the Forth imperative not to name something once >> and for all that is a matter of personal taste and implementation strategy. >I'd rather see one standard--even if it's limited--CASE method instead of >dozens of incompatible ones. Like I said, X3J14 chose exactly what we at VESTA already have implemented! So I can't complain. I'm just saying that I'm not ideologically enthusiastic about it. Not even worth another proposal now that we are so close to dpANS. -- <jax@well.{UUCP,sf.ca.us} >< Member, > /// ///\\\ \\\ /// <well!jax@lll-winken.arpa >< X3J14 TC > /// /// \\\ \\\/// <JAX on GEnie >< for ANS > \\\ /// ///====\\\ ///\\\ <SYSOP RCFB (303) 278-0364>< Forth > \\\/// /// \\\ /// \\\
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (01/20/91)
Category 10, Topic 9 Message 11 Fri Jan 18, 1991 B.RODRIGUEZ2 [Brad] at 21:08 EST I can't resist a small quibble with Mitch Bradley here... > [Regarding price per bit of RAM or disk, bits per unit volume, and > speed of processors:] A factor of 200 in 8 years is extraordinary. 200, Mitch? Really? Funny, I don't seem to be able to find 1.6 Meg x 8 bit static RAMs, or 1.2 GHz CPUs, at my local suppliers. Certainly I haven't seen any PCs with 128 Meg of RAM for a few thousand dollars, or 1-Gbyte disk drives for several hundred (although this last is reportedly close). Perhaps you meant 20? :-) - Brad ----- This message came from GEnie via willett. You cannot Reply to the author using email. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, whatever). Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
wmb@MITCH.ENG.SUN.COM (01/29/91)
> > The think I would like to understand better is, what is the > > *disadvantage* of having CASE etc, in an extension wordset? Nobody > Building control structures, integrating data structures into the > system, etc. are all part of the same issue: tools for user control > over compilation. The tools should be there so that people who like I'm talking about a completely separate issue. I *entirely* agree that the tools should be there. I am NOT arguing AGAINST the tools. I am arguing FOR the "derived" construct, IN ADDITION to the tools. > The Eaker CASE statement is an application Well, my definition of "application" is something that you go down to the store and buy because it solves a substantial problem. Like a word processor or a tax preparation program or an inventory management system. The CASE statement is a language construct; at least that's how 99.9% of the computer programmers that I know would classify it. The fact that it can be built in terms of other language constructs does not affect its utility. The fact that I can build a flip-flop out of NAND gates does not imply that a flip flop is not a very useful and important element of my "design language". Neither does it imply that NAND gates should be discarded. My view is that the more useful stuff we can agree on, the less time that Forth programmers will spend fooling around reinventing the same wheels that Forth programmers have been reinventing for the last 10 years. I want to use Forth to make money. The more "off the shelf" standard tools that I can get, the more useful programs I can write, and the less documentation I have to write about the "custom" tools that I had to build. Mitch Bradley, wmb@Eng.Sun.COM
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (02/04/91)
Category 10, Topic 9
Message 16 Sun Feb 03, 1991
W.BADEN1 [Wil] at 13:21 PST
Here is one of the many ways to portably implement the Eaker CASE statement
without using control flow extension words. It does not matter what the
control flow stack is, but structures must be properly nested.
VARIABLE Cases
: CASE Cases @ ( oldCases) 0 Cases ! ; IMMEDIATE
: CASE? ( N1 n2 -- true, or N1 false) OVER = DUP IF NIP THEN ;
: OF COMPILE CASE? [COMPILE] IF 1 Cases +! ; IMMEDIATE
: ENDOF [COMPILE] ELSE ; IMMEDIATE
: ENDCASE
Cases @ 0= ABORT" No cases." COMPILE DROP
Cases @ 0 DO [COMPILE] THEN LOOP
Cases ! ; IMMEDIATE
Alternatively OF could be expanded in full.
: OF COMPILE OVER COMPILE = [COMPILE] IF COMPILE DROP
1 Cases +! ; IMMEDIATE
When I first became involved with Forth a dozen years ago I could not
understand why Forth does not have a case statement, since all the profane
languages do. With experience there came the understanding why a case
structure is superfluous in Forth.
A case structure takes a single value and makes a series of tests for
equality. Without a case statement a profane language would have to specify or
evaluate the subject of the test for each test explicitly.
In Forth this can be done with DUP or OVER.
An even worse "defect" was the lack of ELSIF for a series of tests. With more
than two alternatives nesting of IFs becomes intolerable.
Eventually I appreciated good Forth coding style, which factors complexity.
Any series of tests worthy of ELSIF deserves its own definition.
( "Thirty days hath September,....")
: days ( Month -- days) : days ( Month -- days) CASE
Sep CASE? IF 30 EXIT THEN Sep OF 30 ENDOF
Apr CASE? IF 30 EXIT THEN Apr OF 30 ENDOF
Jun CASE? IF 30 EXIT THEN Jun OF 30 ENDOF
Nov CASE? IF 30 EXIT THEN Nov OF 30 ENDOF
Feb CASE? IF Feb OF
Year @ 4 MOD IF 28 ELSE 29 THEN Year @ 4 MOD IF 28 ELSE 29 THEN
EXIT THEN ENDOF
DROP 31 ; 31 SWAP
ENDCASE ;
: Craps : Craps
Dice ( Point) CR DUP . Dice ( Point) CR DUP . CASE
2 CASE? IF Lose EXIT THEN 2 OF Lose ENDOF
3 CASE? IF Lose EXIT THEN 3 OF Lose ENDOF
7 CASE? IF Win EXIT THEN 7 OF Win ENDOF
11 CASE? IF Win EXIT THEN 11 OF Win ENDOF
12 CASE? IF Lose EXIT THEN 12 OF Lose ENDOF
BEGIN ( Point) BEGIN ( Point)
Dice ( Point throw) DUP . Dice ( Point throw) DUP .
7 CASE? IF DROP Lose EXIT THEN 7 CASE? IF DROP Lose EXIT THEN
CASE? CASE?
UNTIL ( ) Win ; UNTIL ( ) Win
ENDCASE ;
The CASE statement takes fewer words and more lines. It is also constrictive.
If you want to extend the tests you can make then you have to make more and
more special-case CASE-definitions.
The classical Forth CASE? is just enough semantic sugar, but if you think even
this is too sweet, "foo CASE? IF" could be replaced by "DUP foo = IF DROP". A
range can be done "DUP first limit WITHIN IF DROP". Drop DROP if the value is
needed.
Here is some more semantic sugar.
: ANDIF COMPILE DUP [COMPILE] IF [COMPILE] DROP ; IMMEDIATE
: ORIF COMPILE DUP COMPILE 0= [COMPILE] IF [COMPILE] DROP ; IMMEDIATE
: days ( Month -- days)
Sep CASE? ORIF Apr CASE? ORIF Jun CASE? ORIF Nov THEN THEN THEN
IF 30 EXIT THEN
Feb CASE? (and the rest as before)
: Craps
2 CASE? ORIF 3 CASE? ORIF 12 CASE? THEN THEN IF Lose EXIT THEN
7 CASE? ORIF 11 CASE? THEN IF Win EXIT THEN
BEGIN ( and the rest as before.)
-----
This message came from GEnie via willett. You cannot Reply to the author
using email. Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, whatever).
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp