Digest #75 2019-08-12
Contributions
requestClarification - Does LIST transfer data to any buffer?
I just want to get clear whether LIST moves data from the block into any buffer, or just displays it without doing anything to any block buffer. The description seems to imply it displays only, without changing the contents of any buffer. Just want to be sure.
Replies
requestClarification - Environment dependence of test cases
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.
I found the answer to what I needed to know in Appendix C of Forth Programmer's Handbook.
Yes, I think the system should set BLK to zero at some place between saving the old input source specification and interpreting.
The purpose is that programs that use BLK to determine that they are LOADing from a block work as intended. The Forth standard uses BLK and SOURCE-ID for this: In the old days, when we only had the user input device and blocks, BLK was sufficient; with INCLUDED and EVALUATE, we also got SOURCE-ID. Practically, I think the main use of BLK is to differentiate between a line and the whole screen (e.g., for , while for all other input sources PARSE and PARSE-NAME do not switch to the next line themselves.
The purpose of setting BLK in EVALUATE is probably to make programs that just look at BLK (in particular, pre-Forth-94 programs) behave the same whether EVALUATE is called from a LOADed screen, or from somewhere else.
Could you give a summary of the answer you found?
My take on your question is that block u might already be in a buffer before the LOAD. In that case, LOAD does not transfer the block from mass storage, only interpret what is already in the buffer. However, if the block is not in a buffer already, LOAD loads it into a buffer first.
Sure...on page 249 of "Forth Programmer's Handbook" (Conklin and Rather) it says basically that LOAD causes interpretation from the current input source to be suspended and then input comes from the specified block until it's reached the end. Nowhere does it mention affecting any block buffer. Seems like LIST should work the same way with respect to block buffers.
But now I'm not so sure I've got this right, or that I'm reading that Appendix C correctly. From the description of LOAD here, it really seems to implicitly assume that the data from the "mass storage device" (for me it's an I2C EEPROM actually) is transferred to a block buffer. That does make life easier. I think it should be clarified with an explicit description of whether the block buffers are affected, because it can potentially invalidate previously generated pointers to block buffers. Granted, it's kind of a far-out scenario, but if LOAD or LIST potentially overwrite block buffers, then addresses that may have been obtained before from BLOCK may no longer point to the right data.