wmb@MITCH.ENG.SUN.COM (Mitch Bradley) (01/23/91)
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