>IN

( -- a-addr )

a-addr is the address of a cell containing the offset in characters from the start of the input buffer to the start of the parse area.

Testing:

VARIABLE SCANS
: RESCAN? -1 SCANS +! SCANS @ IF 0 >IN ! THEN ;

T{   2 SCANS ! 
345 RESCAN? 
-> 345 345 }T

: GS2 5 SCANS ! S" 123 RESCAN?" EVALUATE ;
T{ GS2 -> 123 123 123 123 123 }T

\ These tests must start on a new line
DECIMAL
T{ 123456 DEPTH OVER 9 < 35 AND + 3 + >IN !
-> 123456 23456 3456 456 56 6 }T
T{ 14145 8115 ?DUP 0= 34 AND >IN +! TUCK MOD 14 >IN ! GCD calculation
-> 15 }T

ContributeContributions

mcondronavatar of mcondron Environment dependence of test casesRequest for clarification2019-08-03 12:56:27

The last two tests seem to depend on a 32-bit cell width.

GerryJacksonavatar of GerryJackson

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.

mcondronavatar of mcondron

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.

Reply New Version

ruvavatar of ruv Etymology of ">IN" nameRequest for clarification2019-08-26 12:25:27

What do > and IN mean in the >IN name?


For comparison, in other names the greater-than sign apparently has the following meaning (when it does not mean greater-than).

In the words like >R and R>> means data moving direction, and R means the returns stack.

In the words like >NUMBER, D>S or >BODY> means conversion, and a word after the sign is a hint for the target value.

MitchBradleyavatar of MitchBradley

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.

Reply New Version