From Newsgroup: comp.lang.forth

This posting is a more general reflection about designing types in
Forth; it just uses recognizers as example.

The original proposal for recognizers had R:FAIL as the result of a
recognizer that did not recognize the input. Later that was renamed
to NOTFOUND; then there was a proposal where 0 would be used instead,
and Bernd Paysan changed all the uses of NOTFOUND in Gforth to 0.
Finally, on last Thursday the committee decided to go with
TRANSLATE-NONE for that result.

Bernd Paysan thought that it would be easy to change back to a non-0
value for TRANSLATE-NONE, by looking at the patch that changed
NOTFOUND to 0. However, in the meantime there has been more work
done, so it's not so easy.

E.g., there was a word

?FOUND ( x -- x )

that would throw -13 if x=0. This word was used both with the result
of recognizers and with nt|0 or xt|0. Fortunately, in this case the
cases were easy to recognize, and they are now addressed by two words: ?REC-FOUND (for recognizer results) and ?FOUND (for x|0).

What do we learn from this? Merging two previously separate types
such that they are dealt with (partly) the same words (e.g., 0= in
this case) is easy, as is mixing two kinds of sand. Separating two
previously (partly) merged types to use type-specific words is a lot
more work.

You can fake it by defining 0 CONSTANT TRANSLATE-NONE, but then you
never know if your code ports to other systems where TRANSLATE-NONE is non-zero. For now Gforth does it this way, but I don't expect that to
be the final stage.

Should we prefer to separate types or merge them? Both approaches
have advantages:

* With separate words for dealing with the types, we can easily find
all uses of that type and do something about it. E.g., a while ago
I changed the cs-item (control-flow stack item) in Gforth from three
to four cells. This was relatively easy because there are only a
few words in Gforth that deal with cs items.

* With a merged approach, we can use the same words for dealing with
several types, with further words building upon these words (instead
of having to define the further words n times for n types). But
that makes the separation problem even harder.

Overall, I think that the merged approach is preferable, but only if
you are sure that you will never need to separate the types (whether
due to a committee decision or because some new requirement means that
you have to change the representation of the type).

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2025 CFP: http://www.euroforth.org/ef25/cfp.html
EuroForth 2025 registration: https://euro.theforth.net/
--- Synchronet 3.21a-Linux NewsLink 1.2