Digest #170 2022-01-30
: 2SWAP ROT >R ROT R> ;
I have a soft spot for the symmetry in this one.
The set of conditions, if any, under which a "space" delimiter matches control characters is implementation defined.
So the standard makes no guarantees to programs wrt space-delimited parsing, with one exception: 11.3.5 says:
When parsing from a text file using a space delimiter, control characters shall be treated the same as the space character.
But AFAICS in EVALUATE, a standard system may choose to treat only BL as delimiter in that case, or it can also treat other control characters (including newline characters) as space delimiters. I recommend the latter.
When parsing with delimiters other than space (and none of the newline characters), the newline characters must be treated like any other non-delimiter. And when parsing with a newline character as delimiter, that character has to be treated as delimiter.
In most Forth systems the implemented interpretation semantics for
[ are to do nothing. Probably in some systems they are to throw an exception.
And I don't have any idea how a program can rely to the former implementation variant. Could anybody provide a program example that has a benefit due to interpreting the word
[ in interpretation state?
I can only imagine a situation when a user in REPL accidentally uses
[ in interpretation state, and one system just interprets it without any side effects, but another shows an error message.
So a question is: why is one variant preferred over another?