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.