,---------------.
| Contributions |
`---------------´


,------------------------------------------
| 2019-07-09 12:54:28  ruv  wrote:
| requestClarification - Address between runs
| see: https://forth-standard.org/standard/core/BUFFERColon#contribution-91
`------------------------------------------
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.



,------------------------------------------
| 2019-07-09 17:08:46  ruv  wrote:
| comment - Etymology and naming convention issue
| see: https://forth-standard.org/standard/core/PARSE-NAME#contribution-92
`------------------------------------------
In the following definition names: [`NAME>STRING`](https://forth-standard.org/standard/tools/NAMEtoSTRING), [`NAME>INTERPRET`](https://forth-standard.org/standard/tools/NAMEtoINTERPRET), [`NAME>COMPILE`](https://forth-standard.org/standard/tools/NAMEtoCOMPILE) 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` )




,---------.
| Replies |
`---------´


,------------------------------------------
| 2019-07-09 14:40:02  ruv  replies:
| requestClarification - the confusing names
| see: https://forth-standard.org/standard/core/BUFFERColon#reply-248
`------------------------------------------
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.



,------------------------------------------
| 2019-07-09 15:56:23  ruv  replies:
| proposal - BL rationale is wrong
| see: https://forth-standard.org/proposals/bl-rationale-is-wrong#reply-249
`------------------------------------------
Yet another way to find the system value of "space" is  `: _BL ( -- c ) S"  " DROP C@ ;`