[91] 2019-07-09 12:54:28 ruv wrote:

requestClarification - Address between runs

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.

[92] 2019-07-09 17:08:46 ruv wrote:

comment - Etymology and naming convention issue

In the following definition names: NAME>STRING, NAME>INTERPRET, NAME>COMPILE and FIND-NAME (in a proposal) — the "NAME" part means (connotates) a name token. The same for >NAME and NAME> from Forth-83 standard (where it was a name field).

This 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. PARSE-LEXEME )

b. Use some another word in place of "NAME" in the names in the first group. For example "NT" (e.g. FIND-NT )

[r248] 2019-07-09 14:40:02 ruv replies:

requestClarification - the confusing names

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 BUFFER: does?

It looks like a strange inconsistency in the naming conventions.

[r249] 2019-07-09 15:56:23 ruv replies:

proposal - BL rationale is wrong

Yet another way to find the system value of "space" is : _BL ( -- c ) S" " DROP C@ ;