[111] 2019-08-28 13:06:05 ruv wrote:

requestClarification - Ambiguous conditions

An excerpt from 11.3.3 Input source

A standard program shall not call REPOSITION-FILE on the fileid returned by SOURCE-ID.

Is it correctly to say that an ambiguous condition exists if REPOSITION-FILE is applied to fileid returned by SOURCE-ID?

Shouldn't the Standard also say that a standard program shall not change the state of the input source via other words like WRITE-FILE, READ-FILE, READ-LINE, CLOSE-FILE, etc?

This question is connected with REFILL since the statement "attempt to read the next line from the text-input file" can create a wrong impression that READ-LINE may be applied to fileid from SOURCE-ID and REFILL should take the next line correctly after that.

[r292] 2019-08-27 02:49:28 MitchBradley replies:

requestClarification - Etymology of ">IN" name

IN is another of those historical things that is the way it is "just because". The language has evolved over time, and so have the naming conventions. What makes perfect sense to one person might make no sense at all to another. In this case the only justification I can think of is that >IN lets you rewind the input buffer so it is sort of like "to the input buffer", but that answer is not very satisfactory. Perhaps somebody who was part of the FIG Forth team might be able to resurrect the thought process that led to the name, but I doubt it. It might even have preceded FIG Forth, so that the FIG Forth team inherited the name from e.g. FORTH, Inc. or Chuck. If the name came from Chuck, there is no telling what he was thinking at the time, since he doesn't let himself get bogged down by consistency - which is one reason he has accomplished so much.

[r293] 2019-08-28 15:45:04 ruv replies:

proposal - find-name

However, both approaches have been known for at least two decades, and have seen little to no uptake in standard systems. And we have good approaches for implementing systems with name tokens, so excluding these approaches is not a significant loss.

I dislike the idea of excluding other approaches. Particularly, NAME>INTERPRET and NAME>COMPILE are suitable for "dual-xt" approach only, but they are in TOOLS EXT word set, so they don't exclude other approaches (e.g. "state-smart" approach).

This proposal does not mention in what word set the FIND-NAME and FIND-NAME-IN words should be located. Since these words are useless without the NAME>STRING and NAME>INTERPRET words that are in the TOOLS EXT word set, these words should be in the TOOLS EXT too. In such case this proposal is not excluding other approaches.