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


,------------------------------------------
| 2019-08-28 13:06:05  ruv  wrote:
| requestClarification - Ambiguous conditions
| see: https://forth-standard.org/standard/file/REFILL#contribution-111
`------------------------------------------
An excerpt from [11.3.3 Input source](https://forth-standard.org/standard/file#file: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](https://forth-standard.org/standard/file/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.




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


,------------------------------------------
| 2019-08-27 02:49:28  MitchBradley  replies:
| requestClarification - Etymology of ">IN" name
| see: https://forth-standard.org/standard/core/toIN#reply-292
`------------------------------------------
>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.


,------------------------------------------
| 2019-08-28 15:45:04  ruv  replies:
| proposal - find-name
| see: https://forth-standard.org/proposals/find-name#reply-293
`------------------------------------------
> 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.