On Jan 14, 6:34 am, Albert van der Horst <alb...@xxxxxxxxxxxxxxxxxx>
A similar situation is with BLK. One could change BLK and start
interpreting at the same >IN in a different block.
Or setting 0 in it and jump in the middle of the terminal
input buffer. ("An ambiguous condition exists if >IN now points
to an invalid position in the t.i.b." etc. )

Whether or not you COULD do it, it would be silly - if you want to
move to an absolute block #, BLOCK does that, and if you want to move
to a block number relative to the current one, BLK @ BLOCK and adding
or subtracting does that.

My feeling is that the standard should only entitle to inspect
BLK and SOURCE-ID in a standard program and should leave it
to language implementers to change it. Even if it fails to mention
it, that is probably the spirit of the standard.

You couldn't change SOURCE-ID directly if you wanted to, it places the
value directly on the stack.

Obviously, if you wish to, you can USE the fileid for file operations,
and if you wanted to reposition the file to the start and start
repeatedly reading lines and interpreting the line, I guess it'd give
you a second pass. Of course, second time through, SOURCE-ID would
indicate interpreting a string, so it'd only be two passes, or else
optionally go back to execute a section you'd passed over previously
for some reason ... though there'd seem to be multiple more
straightforward ways to do that.

All in all, can't see off the top of my head why you'd want to do it
for manipulating a file in the *process* of including it, but I can
imagine a document file that has its editor as its first line, and
jumps into the editor when you INCLUDE the file. Or, indeed, a source
file that has a particular block comment word as its first line, where
that block comment word is in EDIT vocabulary the name or alias for an
own-file editor. Then it edits itself when you include it rather than
being executed.