ir230@sdcc6.ucsd.edu (john wavrik) (01/16/91)
ANSI and Functionality Traditional Forth has a high degree of functionality because it can build many things. It can even build things which, in conventional languages, would have to be designed in. It allows the user to interact with a computer at a very low level without the usual disadvantages of assembly language. It is precisely this functionality which makes Forth the language of choice for certain application areas. > Cheese louise, why are people so jealous about a few names? The > name space is huge. Some of the discussion following the posting about CASE statements suggests a misunderstanding -- this is not a discussion to quibble about the use of a word -- the real issue is maintaining the functionality of Forth. I received a private response to my posting on CASE from a member of the ANSI team. He told me that it was necessary for the ANSI team to include a CASE statement because under the proposed ANSI standards it would no longer be possible for users to write one. As it happens, he is wrong about the Eaker CASE statement -- but he may well be right about many of the other capabilities associated with traditional Forth. What is of concern to us is the impression that the ANSI team thinks this is OK. They'd find it acceptable to trade a CASE statement for the ability to write one! I'd probably say the same thing that Mitch Bradley said: > Nearly everything is wrong to some degree or another, but you don't > throw useful things away unless you have or can afford a > replacement. I think that what is really behind the current debate is the sense that functionality is being eliminated from Forth. The user's ability to exercise control over the language, and in particular the process of compilation, is an essential characteristic of Forth. The words BRANCH and ?BRANCH, for example, and the functionality they represent, have been part of Forth for a long time. They appear in FIG-Forth (where ?BRANCH is 0BRANCH) and are part of the Forth-83 Standards. They are certainly part of common practice. History and common practice support the claim that the ability to shape the language by creating new control and data structures are part of what makes Forth Forth -- and part of what makes Forth useful. "You don't throw useful things away unless you have or can afford a replacement." ------ I feel it is a misrepresentation to characterize those who insist on retaining Forth's functionaliy as cavemen -- but I will allow for the possibility that this characterization comes from a misunderstanding of the nature of Forth rather than malice. Very few of us do all our programming with "bare" Forth systems -- we, instead, use Forth to build "languages" or "systems" suited for particular problem areas. It is the nature of Forth (part of its functionality) to support this. Most of the systems I use, for example, include BIGNUM arithmetic (integers of arbitrary size). In some parts of mathematics, this is more important than floating point. This is a language feature which I need -- and which Forth allows me to integrate in so completely that it looks built-in to the language. I also have a variety of data representation and storage management packages which I can add as appropriate. There are so many language features that may be needed by at least some part of the mathematical community (to name just one group) that it is unrealistic to expect a single language to have them all. Some are so special or experimental that one can't expect a commercial effort to produce them. What is the solution? I think it's to use a language that allows you to build language features. [Actually, I think that this is a solution to a lot of peoples' programming problems -- but they don't know it yet. The Forth community seems too preoccupied to support the kind of education effort which would be needed to get this message across.] Please note very carefully that nothing in the previous paragraph says that I would not be willing to use (or even buy) features implemented by others. My interest in a good Standard for Forth is to make this possible. I would have been quite happy to have a BIGNUM package written by someone else (provided that it works, or could be modified to work, as I need it to). I am also interested in seeing a good Standard so that, once I have taken trouble to add a particular feature to Forth, it will be useful on many platforms over a long period of time. It would be absurd if the Forth community cannot produce a Standard which insures sufficient power and portability for this. Please also note that I am not running to the ANSI team with a proposal that BIGNUM arithmetic (or any other of the language features I find useful) be incorporated in the Standard. I don't think this is a feature that should be part of Forth -- just the ability to build it! I see no necessary conflict between those who want Forth to retain its capacity to build language features and those who want the glossary for certain popular features to be standardized. I do see a conflict with those who want to include features and eliminate the tools needed to build them. John J Wavrik jjwavrik@ucsd.edu Dept of Math C-012 Univ of Calif - San Diego La Jolla, CA 92093