Digest #63 2019-07-10
It seems this word specification intents that a compiled program can be saved into an image and run from the image multiple times.
May a system provide different addresses between runs?
1024 BUFFER: foo foo CONSTANT bar \ use bar in the code further
This code is either standard or not standard depending on the answer. If it is not standard, an ambiguous condition should be mentioned in the specification.
In the following definition names:
FIND-NAME (in a proposal) — the "NAME" part means (connotates) a name token. The same for
NAME> from Forth-83 standard (where it was a name field).
PARSE-NAME definition has nothing to do with the name tokens. And "NAME" part means something else in this case. It means (connotates) a sequence of arbitrary characters delimited by space.
This difference in meaning exposes an inconsistency in the naming convention. This inconsistency can be solved in the following ways:
a. Use some another word in place of "NAME" in this definition name. For example "LEXEME" (e.g.
b. Use some another word in place of "NAME" in the names in the first group. For example "NT" (e.g.
Another issue with this name is a colon at the end. There are many standard parsing words that take one argument from the input. Some of them do not have a colon at the end, but some other (mostly new) have a colon. What is the rule? if
CONSTANT does not have a colon in its name, why
It looks like a strange inconsistency in the naming conventions.
Yet another way to find the system value of "space" is
: _BL ( -- c ) S" " DROP C@ ;