Digest #238 2023-12-02
Contributions
At some point (hopefully soon) the editor (i.e., I) will integrate the accepted proposals into the standard document. In order to see which proposals have yet to be integrated, I would like to have one of the following:
A proposal state "accepted and integrated", that is reached from "accepted" once it is integrated into the document. I would prefer this.
Sorting of the accepted proposals by acceptance date/acceptance reply, not by proposal number. In that case I could track what is the most recently accepted proposal that has been integrated, and not consider any proposal below. As it is, an accepted proposal can appear anywhere in the list of accepted proposals, and I would have to scan that repeatedly (with the danger of missing one). This order may also be useful for other users of forth-standard.org, because they also want to keep up-to-date on the accepted proposals without repeatedly scanning the list.
Replies
I think, the initial intention was that the Forth text interpreter may use word (and find, as well as the pictured numeric output string buffer) by itself. These means were standardized not as a separate facilities for programs, but as the facilities that Forth systems already used by itself. So it's simply an oversight that the corresponding restriction is not normatively mentioned.
Another argument is that a user might implement a user-defined text interpreter using word and find (or the Recognizer API), and it must not make system non-standard.
Given that I have seen confused questions by users over the clobbering behaviour by some systems several times,
It means, users still use word. And then, they can use word in their own text interpreter, so they should be warned.
I agree that this is an oversight in (and since) Forth-94. I think that we can therefore remove the guarantee that the text interpreter (and, I guess, some parsing words) to not clobber the WORD buffer without making this guarantee obsolescent for one version of the standard. The question is if we want that.
As for users writing their own text interpreter and the result still being a standard system:
When dealing with the "clarify FIND" proposal, it turned out that there is no consensus that the Forth standard should support writing a user-defined text interpreter, and that there is no common practice that would allow that.
There is currently no way to plug a user-defined text interpreter into the system, so your user-defined text interpreter will not change how the system parses.
Yes, users use WORD, but not many use it for writing a text interpreter, and if they do (e.g., in Bernd Paysan's OOF), the result does not change the system, and therefore the WORD-using user-defined text interpreter does not make the system non-standard.
proposal - Relax documentation requirements of Ambiguous Conditions
Yes, the choices on the ballot do not fit the proposal.
For programmers, good choices would be:
- I have looked into a system's documentation for ambiguous conditions, and found it helpful.
- I have never found a system's documentation for ambiguous conditions helpful (possibly because I never looked there).
For systems, good choices would be:
- <system>'s documentation satisfies the requirements.
- <system>'s documentation will document the behaviour of the system on all ambiguous conditions in 4.1.2 even if it is not required.
- At some point <system>'s documentation will not document the behaviour of the system on all ambiguous conditions in 4.1.2 if it is not required.
Note that the three choices for the system are not all mutually exclusive. So checkboxes are more appropriate than a drop-down menu or radio buttons. And of course the committee member starting the CfV must have a way to specify the choices. Plus, for other votes, it should be possible to specify system versions for some choices.