Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!usc!ucsd!ucbvax!MITCH.ENG.SUN.COM!wmb
From: wmb@MITCH.ENG.SUN.COM (Mitch Bradley)
Newsgroups: comp.lang.forth
Subject: ANS - a house with no bathroom?
Message-ID: <9101222216.AA12047@ucbvax.Berkeley.EDU>
Date: 22 Jan 91 19:44:22 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: Mitch Bradley <wmb%MITCH.ENG.SUN.COM@SCFVM.GSFC.NASA.GOV>
Organization: The Internet
Lines: 73

The claim that ANS Forth is like a house with no bathroom is overstated.

ANS Forth is indeed missing a few things, but none as crucial as a
bathroom to a house.  It's more like a house with central heating,
but missing a fireplace.

The "missing piece" that Dr. Wavrik has mentioned recently is the inability
to create arbitrary custom control structures.  Based on his concern, and
also my own personal concern about this issue, I have promised to bring up
this issue at next week's meeting, and to fight vigorously for its
resolution.

To this end, I have been in contact with Dr. Wavrik, David Petty, Wil
Baden, and others, collecting data, ideas, arguments, and counter-arguments.
I expect to prepare 2 proposals, each suggesting a different solution to
the problem, in the next few days.

The gist of the proposals will be:

1) Specify that "destination" tokens (the things that are produced and
   consumed at compile time by control flow words) appear on the data
   stack as double-cell numbers.

2) Add the words SO and STILL to the CORE EXTENSION wordset.  SO is
   essentially "PICK" for destination tokens, and STILL is essentially
   "ROLL".

Proposal (1) has the advantage of not adding any new words.
Proposal (2) has the advantage of not constraining implementors to
a particular choice for the format of "destination" tokens.

Either proposal would complete the control flow wordset.

Another alternative is to add the words BRANCH , ?BRANCH , >MARK ,
>RESOLVE , <MARK , and <RESOLVE .  I have chosen not to propose this,
because, in my judgement, it has very little chance of passing.  The
reasons:
   (a) it is 6 words, and there is considerable committee sentiment
       against the addition of words
   (b) BRANCH and ?BRANCH seem to imply a threaded code compilation
       model, and ANS Forth is intended to encompass a variety of
       compilation models, not limited to threaded code.
   (c) Some committee members have already stated an intense dislike for
       >MARK, etc, and several vendors did not implement them after
       they were put in Forth-83.

I believe I could make a technical case that BRANCH does not ACTUALLY
imply a threaded compilation model, but I doubt that I could convince
enough people of that in a reasonable amount of time.

The final alternative is to add BRANCH and ?BRANCH and to further specify
exactly what is stored in memory following them.  This alternative has
no chance at all of passing, because it definitely implies a threaded
compilation model.  Furthermore, it also implies the addressability of
compilation space using the normal @ , ! operators, which is not true
in implementations like F-PC, which use a segmented memory model.

If someone else wishes to submit a specific proposal to add BRANCH ,
?BRANCH , >MARK , >RESOLVE , <MARK , and <RESOLVE , I will be happy
to personally defend it at next week's meeting.  I choose not to do
so myself because I would rather spend my time on alternatives (1) and
(2), which I believe have a far better chance of passing.

Now, one might claim that SO and STILL are not a fireplace, but instead
a wood-burning stove.

In my quest for ANS Forth solutions, I have long since given up on the
hope that all my favorite solutions will be adopted.  Instead, I focus
on ensuring that some solution exists; hopefully the "best possible",
but failing that, at least the best that will survive the consensus
process.

Mitch