6.1.0560 >IN to-in CORE

You are correct for the test;

`T{ 123456 DEPTH OVER 9 < 35 AND + 3 + >IN ! -> 123456 23456 3456 456 56 6 }T```

because the integer 123456 is too big for a 16 bit system. This test was taken from the coreplustest.fth in the ANS/Forth 2012 test suite on Github. The test there is now:

T{ 12345 DEPTH OVER 9 < 34 AND + 3 + >IN ! -> 12345 2345 345 45 5 }T

I'm not entirely sure but I think it used to contain the integer 123456 and someone else pointed out it was too big and it was changed to 12345. The test in the TESTING section above must have been copied from an old version of the file. Looking at a history file I see that it was changed in version 0.12. The initial commit on GitHub was version 0.13. The keeper of the Forth200X standard should change the test to the line above.

Regarding the other test:

T{ 14145 8115 ?DUP 0= 34 AND >IN +! TUCK MOD 14 >IN ! GCD calculation -> 15 }T

the integers fit into 16 bits so I don't understand your comment.

First of all, thank you very much for clarifying the history of this test and providing a workable 16-bit version!!

Second, I was making a mistake using these tests.

Every other test that I've run here -- and I do not have the test harness, so I just copy the code between T{ and -> and paste it into my Forth, then look at the stack -- every other test works doing that. But these two are special in that they require the T{ at the beginning of the line because they manipulate the >IN variable and rely on having T{ at the beginning.

Furthermore, the second test also relies on "GCD calculation" at the end, and for some reason, when I first read this and tried it, I thought that was a comment, but I see now it's needed for this to work.

Now I have both these tests working.

Thanks again.

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.

Proposed change to the definition of RESCAN?

This would make the make it more friendly to block based implementations and would not require the input to begin at the beginning of a line.

: RESCAN? >IN @ >R -1 SCANS +! SCANS @ IF R@ >IN ! THEN R> DROP ;

Please disregard this. It does not work at all. Sorry about the noise.

>IN produces the address of a cell, and storing to that address is one of the standard operations one can use addresses for. If the standard committee did not intend that, the standard would specify that explicitly, as in the case of STATE.

You find some of the answers to your questions in 3.4.1 Parsing:

the selected string begins with the next character in the parse area, which is the character indexed by the contents of >IN. An ambiguous condition exists if the number in >IN is greater than the size of the input buffer.

That section also mentions one specific case of storing into >IN.

The value in >IN is an offset in characters, so increasing it by 1 means that the parse area now starts at the next character, even if 1 chars > 1. So character alignment of the value in >IN would not make sense.

Adding "See also: 3.4.1 Parsing" to 6.1.0560 would be useful, however.

All questions are answered, so I am closing this. If anything is unclear, please reopen it.

All the words you list have been standardized only for application use. That is most obvious for source, refill and save-input, which were introduced in Forth-94 to provide an abstraction from the different mechanisms is for input from the terminal, from blocks, files, and evaluated strings. Forth systems don't need these words internally, and they certainly don't need their standardization for their internal uses.

>in has a longer legacy and one can consider it as exposing a system-implementation word of early Forth systems. However, the fact that it is standardized is not for the benefit of systems, but for the benefit of programs. As system implementor I disliked the need to keep >in up-to-date, and to start the next parse from >in. Is it the ideal interface? Probably not, but it is common practice.

Given that these words have not been standardized for internal system usage, a distinction like you suggest makes no sense.

The standard has the Programming-Tools wordset, which collects a variety of words that some might consider to be outside the scope of application programming. The criteria for inclusion in the Programming-Tools wordset are unclear, probably even to the members of the committees who made these decisions; one idea might be that if the feature is not in a language like Pascal, then it's a programming tool (note that already C has conditional compilation, which is in Programming Tools). Interestingly, none of the words you mention are in the Programming Tools wordset, so apparently the Forth-94 committee thought that they (especially >in and source, which are in the Core wordset) are more widely useful.

@AbstractionFirst, your comment is completely irrelevant to the glossary entry >IN. It should have been posted elsewhere.

Would it be beneficial for future revisions of the standard to distinguish these interfaces explicitly, perhaps by introducing a separate word set

Moving glossary entries from one section (word set) to another is possible in principle, but it has its drawbacks and does not offer significant benefits. A simpler approach is to add tags to glossary entries indicating which groups the word belong to. In any case, this should be discussed in a separate proposal. So, I close this comment.