ir230@sdcc6.ucsd.edu (john wavrik) (04/22/91)
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 Nick_Janow@mindlink.bc.ca (Nick Janow) (04/23/91)
ir230@sdcc6.ucsd.edu (john wavrik) writes: > 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. That could be a problem, but the solution is to make clear that the standard's words are not necessarily exactly the same as the ones that you have used in xxxForth. A simple "Warning: the semantics of ANSI Forth words may not be identical to that in previous versions of Forth." printed on the first page (or some other visible place) should be enough. I don't see it as a problem of the contents of the 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. I see it as a new version of Forth that will be offered by several commercial software companies and shareware/freeware writers. How well it does will be determined by the marketplace, the same way F83, MacForth, etc were judged. I expect that the benefits of ANSI Forth--mainly the portability issues--will win it a lot of support. Programmers who find the architecture-independent compromises of ANSI Forth too restrictive probably have applications that are too machine-specific to be portable anyways.
jwoehr@isis.cs.du.edu (Jack J. Woehr) (04/23/91)
In article <18518@sdcc6.ucsd.edu> ir230@sdcc6.ucsd.edu (john wavrik) writes: > >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. Yes, some things can not be done PORTABLY in ANS Forth, John. So what? You will still be able to store to the bodies of CONSTANTs *on your own system* ... Hell, do anything you want. But PORTABILITY implies TRANSPARENCY TO ARCHITECTURE. Is this a difficult concept? >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. Suppose you are right, John? C users depend on PJ Plauger to tell them what ANS C means. I mean, John, you're a *teacher*, right? SO TEACH!!! > 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. Oh, foof, John! It does no such thing. It attempts to remove 16-bittedness and other architecural and implementation dependencies from the PORTABLE syntax. Your personal Forth system can provide you with any hacking tools you want. Just don't expect that assumptions that worked in FIG-Forth will be transportable. > 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). Ok, so who in the C community reads the Standard? They read Plauger's book, that's what they read. Golly, what a shame ... a few more Forth books might get written! :-) >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. > You fail to grasp the Zen of BASIS, grasshopper. What we do NOT say is as important as what we DO say. "The emptiness of the room," said sage Lao Tse, "gives the room its usefullness." John, WHAT ARE WE SUPPOSED TO DO? We could say, "`Comma' compiles sixteen bits." WELL THAT DOESN'T EVEN WORK NOW! My co-worker came into my office to complain to me about my Forth for the 80C196. Seems he had an application from our Forth for the 80188 that had 1234 , 34 c, 678 , 9999 , etc. scattered in an array. Of course it didn't run! The 80196 enforces word alignment on 16-bit quantities! So you just ABSTRACT as much of the architecture dependency as humanly possible from the language model and you have BASIS 15. >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. > Horsefeathers. Meanings are not fuzzed. Your interpretation is skewed. ANS Forth will offer the most unified statement of what for all practical purposes constitutes the essence of the academic model of Forth. BASIS 15 works, John. I've got it running. > 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. > This is byzantine academic hair-splitting. Your ivory tower is showing. The BASIS describes the language. It cannot sufficiently describe the language for the novice. YOU ARE A TEACHER THIS IS YOUR JOB. >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. > 83-STANDARD changed stack indexing from one-based to zero-based. Golly, that's tough. >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!] > We'll find it by doing it, John. Us *working* Forth programmers are great doers and problem mechanics. We'll get it up and running, that's our life! >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. > Yes, the perspective of having participated in this effort. Can you tell me how we could NOT have a shared perspective after sitting in rooms together for years? The Spanish have a saying, "I hear you talking, but you are saying nothing." What is your complaint here? >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. This is utter nonsense and indicates you haven't really read the BASIS, or else you are intentionally misrepresenting the work. >Forth would benefit greatly by a good Standard at this time. The last >thing it needs, however, is a bad Standard. > BASIS 15 is pretty good. >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. > Great, in the year 2002 you tell us if you like it, ok? Meanwhile, us *working* Forth programmers will be writing thousands of portable ANS Forth programs. We'll let you know if we have any problems. I apologize for being huffy, John. It's late. I've been up implementing BASIS 15. I just don't want to hear any more nonsense from sideliners. Implement it and show me where it's broken. I'm sure there are bugs. Please find them and fix them, otherwise just lay off the BASIS. We don't need carpers. We need workers. Implement or shut up. -- # ..!apple!dunike!nyx!koscej!jax # "Therefore, the L-RD G-d # # ..!hplabs!hp-lsd!oldcolo!jax # sent him FORTH ..." # # {apple,hplabs,pacbell,ucb}!well!jax # - Genesis 3:23 # # JAX on GEnie SYSOP RCFB 303-278-0364 # Member ANS Forth X3J14 TC #