wmb@MITCH.ENG.SUN.COM (Mitch Bradley) (11/02/90)
> [ Frank Earl writes ... ] > the use- > > nnn VOCABULARY <name> > > is non-compliant with the standards and, thus CANNOT claim to be 79/83 > standard ... how many of the dialects use the non-compilant definition 1) It's not just the stack diagram of VOCABULARY that is in question. The other consideration is the behavior of word lists defined by vocabulary. FIG Forth: after the vocabulary is searched, its parent vocabulary is searched, and so on. ("chain to parent") Forth 79: after the vocabulary is searched, the FORTH vocabulary is searched. ("chain to FORTH") Forth 83: unspecified, but most implementations adopt the ALSO/ ONLY experimental proposal, in which a run-time list of vocabularies controls the search order. polyFORTH: I'm not sure of the exact details, but I know it's different from any of the above. Consequently, even if one is willing to ignore the systems which require a numeric argument to VOCABULARY , the semantic meaning is inconsistent among existing standards. > If there are only a few (even if they are major vendors' products) why > was the "compromise" made in the first place? According to ANSI rules, major vendors cannot be so easily dismissed. ANSI rules require that a proposed standard be acceptable to existing major vendors. Don't pin me down on the details of this, because I don't know them, but I do know that what I just said is basically true. If someone at Forth, Inc. is listening (Dennis?), perhaps they could ask Elizabeth to clarify this point. Mitch
DAVID@PENNDRLS.BITNET (11/02/90)
Frank Earl writes: >and you have to re-write loads of code) [ PLEASE NOTE- I have YET to see proof >positive that I WON'T have re-write many portions of my 83 standard code or >claim an environmental dependency (Of which, similar code in C DOESN'T HAVE >TO!!)] I'm all for the standard, I'm just getting the feeling that it may hav e I don't know how many times those of us who (I hope) understand what the standard is trying to do have to repeat this before it will sink in, but here goes one more try. Please excuse the emphasis, but I feel like this argument has gone around too many times (not by you, Frank, you just happened by at the wrong moment :-). If you currently have code that is 83 (or 79) standard, then if the vendors rewrite their systems so that they are compliant and do not delete any features (and the standard is specifically designed so that they can do this), then your code will be EXACTLY AS PORTABLE AS IT WAS BEFORE THE STANDARD, no more, AND NO LESS. If you choose to take the time to *rewrite* your code to be ANSI compliant (yes, EVERYBODY will have to rewrite to achieve that) then your code will become portable to EVERY ANSI COMPLIANT SYSTEM, including many on which your code would not (before the standard) have had a prayer running. The standard is not, AND CAN NEVER BE, a magic wand which you can wave and say 'my code is portable'. YOUR CURRENT CODE IS EXACTLY AS PORTABLE AS IT CURRENTLY IS, AND THE STANDARDS COMMITTEE CANNOT CHANGE THAT. To rephrase, the intent is to AVOID BREAKING CODE THAT WORKS NOW, but to provide standard facilities so that code that is FULLY portable CAN be written by those who need to do so. -- R. David Murray (DAVID@PENNDRLS.BITNET, DAVID@PENNDRLS.UPENN.EDU) P.S.: 'Similar code in C' (whatever that is) was portable after the ANSI C standard only insofar as it was portable before the C standard, or because the standard broke somebody else's code. Because C compilers are harder to write, there was more uniformity among C implementations than there are among FORTH implementations, and so there were fewer problem areas. (But, note, I'm *still* not sure how to declare, reference, and initialize a variable at the outermost level of a C program so that it will be portable!)