Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!mips!pacbell.com!ucsd!sdcc6!ir230 From: ir230@sdcc6.ucsd.edu (john wavrik) Newsgroups: comp.lang.forth Subject: 5 Lbs 3 Oz Message-ID: <18518@sdcc6.ucsd.edu> Date: 22 Apr 91 06:21:45 GMT Organization: University of California, San Diego Lines: 252 The recent news that the ANSI team intends to go to the dpANS stage at this point was greeted with the kind of mixed feeling one always has at the announcement of a premature birth. (Discussion first -- Summary at end ) I'd like to stress the importance of a good Standard for Forth. I've met many many people like Sam Smith whose attitude toward the ANSI effort is summarized by "Ho Hum!". Sam does all of his program- ming in Smith-Forth. His applications are hardware-specific and he has no need to have others read his code. He doesn't even expect to use his current code years from now when Smith-Forth has evolved to an incompatible state. I'd like to persuade Sam, and others, to think about interrelation- ships. Sam's ability to derive income from Smith-Forth depends on acceptance of the language in a wider community. In many areas port- ability is an essential quality for a language -- and lack of portability is enough to remove a language from consideration. A definition of portability is given below. The purpose of a Standard is to insure portability. While it is very important for Forth that we have a good standard, the worst thing that can happen is the adoption of a bad one. With all that as background, here are some comments about the present state of the ANSI effort with respect to power and portability. -------------- The analogy of a building project has been used in this newsgroup to describe the ANSI effort. The decision to go to the dpANS stage is like a building contractor's announcement that the project is essen- tially complete. It is technically correct that the builders are obliged to fix certain things after the official completion of build- ing. In practice, however, this does not extend to re-doing parts of the building. dpANS is not a "draft" in the sense of the first draft of a written article. A written article may take quite a different shape by the time it has reached its sixth draft! The announcement of completion of major construction on a building project is a much closer analogy. There seems to be a move afoot to get the Forth community to see the ANSI building effort as a simple room addition to an existing house. We are to believe that our old house is still there -- but a few small extra rooms have been tacked on and a little bit of moderniza- tion has taken place -- nothing to worry about. This could not be further from the truth. Most users must expect to see a building, quite different (perhaps in major ways) from the original. Some of the changes are not immediate- ly visible. Rooms might appear the same but, because of the electri- cal and plumbing disputes, switches and faucets may not work as they did before -- the reasons hidden behind the walls. The proposed ANSI-Forth is not a simple room addition. It is a new language that shares many words (but not always meanings) with the language we now use. It should be honestly presented as a new lan- guage and current Forth users should be given ample time to evaluate it (and to meaningfully participate in revision). In its present state it is not clear that the new language has either power or portability. The BASIS document is to be the definition of this new language. It must serve as our guide to portability. If the ANSI effort does not restore portability to the language, the whole exercise is pointless. The following criteria summarize what we mean when we use the word "portability": Test 1: A and B are programming on two Standard implementations. Can A write significant programs which will run without error on B's system -- without A having access to B's system or even knowing what it is. The requirement is particularly stringent for Forth -- since Forth systems crash easily. There is no friendly compiler to scan A's code and produce diagnostic messages. Ambiguous word meanings lead to hard to detect bugs. Please note that the test specifically requires that A be able to write portable code without having copies of all possi- ble target systems. Test 2: If C implements a version of Forth following the description of the language found in the Standards document, will compatibility as in Test 1 extend to C's system? This is a test of whether the language has been well described by its Standards document. There is more to this than just having words match glossary descriptions. - - - - - After reading BASIS14, I have added Test 0: Would an experienced Forth programmer be able to determine, on the basis of the Standards document, which of his current code is not portable -- and how to replace it by portable code? The ANSI effort in its present state (BASIS14) does not meet any of these tests. The attention of the Forth community is being directed to the words: which are "in" and which are "out". Users are being lulled into assuming that if a word is "there" (in BASIS) that it has the familiar meaning. It is precisely this kind of assumption that leads users to overlook omissions and not see alterations. The problem is most apparent in the "Nitty Gritty Wordset" -- which contains the words like ' , >R ALLOT HERE etc. which refer to the architecture of the virtual machine. To understand the issue let us examine just one word: , (comma). In Forth-83 we have: , 16b -- ALLOT space for 16b then store 16b at HERE 2- ALLOT w -- Allocates w bytes in the dictionary. The address of the next available dictionary location is updated according- ly. Let's read what BASIS14 says about this word: , ( w -- ) Reserve one cell of data space and store w in the cell. An ambiguous condition exists of the address of the next available data location is not aligned. A great point is made about Forth being controlled by semantics rather than syntax. The paragraphs above are presumed to give the "semantics" of comma. Actually they don't. They are descriptions of how comma acts. The semantics of comma has to do with why anyone would want to store numbers in the "dictionary" or "data space". (We can call this the "meaning" of comma if there is a conflict.) Forth is an architecture-based language. Many of its words have meaning in terms of the architecture of the virtual machine. Comma is one of these words. On the basis of the BASIS description, do we now know how to use comma? Do we know why would anyone want to store numbers in the "data space"? Do we know what the "data space" is intended to be? [Read section 5.3.2.1 on "Data Space" in BASIS14 and see if, after reading it, you know what "data space" is intended to be!] If you are a long time user of Forth, you probably have used comma in many ways. You've used it to put data in the parameter field of an object, you've used it to compile an address into a dictionary entry, you've used it to store addresses or displacements for branches. You read the BASIS document *assuming* a meaning for comma. You read your code (which contains only Standard words used in a way consistent with this meaning) and you breath a sigh of relief to find that your code is portable! THE FACT IS THAT YOUR ASSUMPTIONS ARE WRONG. Code that looks perfectly normal and runs perfectly well on your system will not be portable: --The word is the same --The description is the same --But the meaning (semantics in the true sense) has been changed. What has been said here about comma applies to other words as well. The reader should trace through the BASIS document to try to check the meaning of words like >R, R>, ' (tic) etc. To imply that a user of Forth will be able to make existing code compliant by running it through a word processor or including a "prelude" is just plain dishonest. Readers of this newsgroup have been tipped off by the reactions of Mitch Bradley, John Hayes, Elizabeth Rather and others to submitted code fragments. Thus USENET readers have had some indication that certain things which could be done in a relatively straight-forward way in traditional Forth systems may have to be drastically altered (or possibly cannot be done at all) in the proposed ANSI Forth. Most users of Forth are not readers of ForthNET. They will need to rely on definition of the language in the Standards document. Even if there is an "Ask Mitch" column in Forth Dimensions, it will not satisfy the needs of most users. They will ultimately rely on a glossary based on the Standards document for their understanding of what words are available and how they can be used. The BASIS docu- ment, as it stands now, reflects a systematic attempt to fuzz and eliminate word meanings. As a result the average user does not even have the means to identify where existing code fails to be portable, and how to fix it. Neither is he in a position to know if any words are "missing" -- i.e. whether BASIS provides the tools to replace the code (once it has been located). The ANSI project has been an unusual building project. The work has been conducted from a builders' perspective -- decisions have been made for the convenience of the builders. The elimination of meaning is not just a "t" left uncrossed or "i" not dotted -- it is the result of a systematic application of a misconception: if meaning is left vague, they think that the language becomes more flexible. Forth has been looked at from the singular perspective of one group of people. Diverse as they may seem to each other, they share certain assumptions that must be challenged. The idea that word meanings should be fuzzed or eliminated is one of these assumptions. It has its origin in a real short-term advantage (i.e. vendors don't have to change existing products) -- but it has long-term disadvantages to users, teachers, and researchers for whom portability is important. SUMMARY A great point is made about Forth being controlled by semantics rather than syntax. A description of how a word acts is not the real story of its semantics. The semantics of a word (here called its "meaning") includes such things as what the word is typically used to accomplish. The ANSI document includes familiar words with altered meanings. The words are there with the same name and (sometimes) the same semantics -- but they can no longer be used to accomplish the same things. There is no way for most users to locate segments of their existing code which are victims of the evaporation of meaning. It is not clear if the proposed ANSI Forth provides viable work-arounds or how to find them. [The problem is compounded by the fact that the BASIS has been badly translated from the original Hungarian!] This is not a cosmetic problem -- it comes from the fact that BASIS has been put together by people who have come to share a singular perspective. Some of the shared beliefs have evolved in bizarre ways. Fuzzing the meaning of words does make it easier for vendors to call current systems "Standard". This is a short term "gain" which has serious long-term negative effects on a user's ability to write portable programs; on power; and on eventual acceptance of the lan- guage. Forth would benefit greatly by a good Standard at this time. The last thing it needs, however, is a bad Standard. The proposed ANSI-Forth is not a simple room addition. It is a new language that shares many words (but not meanings) with the language we now use. It should be honestly presented as a new language and current Forth users should be given ample time to evaluate it (and to meaningfully participate in revision). In its present state it is not clear that the new language offers either power or portability. John J Wavrik jjwavrik@ucsd.edu Dept of Math C-012 Univ of Calif - San Diego La Jolla, CA 92093