We discussed the following items from the board. Only the first one was moved to done, the others stayed for the next meeting (just before EuroForth).
Decision:
Any such features should not be the main focus of the recognizer proposal. If they fall out of features needed for Forth, that’s ok.
We moved this item to Done.
The participants of the meeting added two other options:
0 on unsuccess?Leon Wagner and Stephen Pelc do not agree: EXECUTEing the result is easier than checking. Anton Ertl thinks that either option is acceptable, but has a slight preference for 0.
Forth-94 has not specified whether FIND should find the visible locals, and some systems do it magically in FIND (Gforth, VFX), while others do it in the text interpreter (SwiftForth).
The recognizer proposal defines internals of the text interpreter, and on some systems (Gforth) even the internals of REC-NT (the replacement of FIND). We should take this opportunity to define how visible locals are recognized. There are two options:
In the recognizer sequence before REC-NT (the FIND replacement)
In REC-NT before searching the search order.
Another question is how the locals recognizer is enabled and disabled (if at all), or if it automatically does not recognize anything when there are no visible locals.
Discussions of all concerned are necessary, but not everybody was present.
Maybe a workshop at the meeting in Hamburg?
With the non-standardization of all words that consume a translator, the translator returned by a recognizer becomes an opaque token.
Given that, it would be more convenient if the word defined by TRANSLATE: has the stack effect ( -- translator ), where translator is the opaque token for the translator. As a result, one would then write, e.g., translate-num instead of ['] translate-num when defining a recognizer that returns a translate-num.
Opinions from all concerned are necessary.