Digest #74 2019-08-10
Contributions
The description of this EVALUATE says to "extend the semantics of [the Core[ EVALUATE" to set BLK to zero...The Core EVALUATE performs a long sequence of steps, the last one of which is to restore the previous input specification...so, the Block modification to EVALUATE presumably sets BLK to 0 just after saving the previous input specification? What is the purpose of this? Presumably to help REFILL behave correctly, but then, which doesn't it already know the input source is not a block if SOURCE-ID is -1? It is kind of confusing, because there are two variables involved: SOURCE-ID and BLK. There are four states
SOURCE-ID =0 BLK=0 Input from user SOURCE-ID=0 BLK<>0 input from block SOURCE-ID=-1 BLK=0 Input from EVALUATE string SOURCE-ID=-1 BLK<>0 Illegal, it would seem, or at least I see no meaning to it.
So why set BLK to 0 if SOURCE-ID seems to necessarily override BLK anyway? Am I missing something?
This word is surely intended to actually transfer the contents of the specified block from the mass storage device to a buffer, but this behavior is not described. From reading the description, it gives the impression that LOAD is meant to be run after a block has been transferred from mass storage. Is that the case? It's not what I get from reading historical documents on this -- it seems LOAD is meant to initiate a transfer of data.
Maybe what's intended is something like: "Save the current input source specification. Read block u from mass storage in the manner described in BLOCK. Make the block buffer where block u was saved be the input source. Set >IN to zero and interpret, then restore the prior input source specification."
It would be very nice if somehow the code for the website could be modified so that when you click on "Search" at the top bar, the cursor automatically goes to the Search text box. As it is now, you have to click the mouse on that box before you can start typing into it.
Replies
referenceImplementation - GNU C RESTRICT would make sense in the standard
Gforth 0.7 and earlier performs -14 throw when text-interpreting a compile-only word.
In the next release all words have interpretation semantics (for compile-only words often the same as the compilation semantics). The meaning of compile-only now is that you get a warning in text interpretation and when ticking.
However it is implemented, after finishing EVALUATE, SOURCE-ID has to produce the previous value. I think that follows from the definition of "input source specification" in 2.1, but it's not that explicit there.
SAVE-INPUT and RESTORE-INPUT only work within one input source (and probably not for the user input device), so saving and restoring SOURCE-ID is not necessary. You may save it and then check it on RESTORE-INPUT, but this does not guarantee that only correct uses of RESTORE-INPUT come through. Consider
s\" save-input s\" restore-input\" evaluate" evaluate
Consider two nested EVALUATEs, or a nesting EVALUATE-INCLUDED-EVALUATE.
This is such a common problem! I've learned to "copy" everything I type before walking away, before clicking on any links, before even thinking of a different topic for a moment. But it's not good. It makes users want to not contribute for fear of wasting time.