18.104.22.1688 INCLUDED FILE
Remove c-addr u from the stack. Save the current input source specification, including the current value of SOURCE-ID. Open the file specified by c-addr u, store the resulting fileid in SOURCE-ID, and make it the input source. Store zero in BLK. Other stack effects are due to the words included.
Repeat until end of file: read a line from the file, fill the input buffer from the contents of that line, set >IN to zero, and interpret.
Text interpretation begins at the start of the file.
When the end of the file is reached, close the file and restore the input source specification to its saved value.
An ambiguous condition exists if the named file can not be opened, if an I/O exception occurs reading the file, or if an I/O exception occurs while closing the file. When an ambiguous condition exists, the status (open or closed) of any files that were being interpreted is implementation-defined.
INCLUDED may allocate memory in data space before it starts interpreting the file.
NickMessenger  Example2023-05-04 15:23:46
This word introduces the concept of individual lines, and
( is extended to support them, however there is no similar extension to
\, which continues to discard the entire rest of the buffer. The use case is a vi-clone screen editor in durexForth, it allows to edit files on disk and press a key to evaluate them as if they were
included. That Forth's
\ ( included evaluate etc were recently brought to standard, so when the editor
evaluates its buffer then
\ comments are broken, but if it separates and
evaluates each line one-at-a-time then
( comments are broken. It would have to essentially reimplement
included on in-memory buffers, maybe provide an non-standard definition of one of
\. I'm actually not really sure how it could be fixed. Other than:
I would propose a new section 22.214.171.1245 so that, when
blk is 0,
\ discards "the rest of the line," where that's defined to be the same as in
Cross-reference durexForth author Johan's question about
(. My opinion is that he's suffering from the XY-problem, not seeing that this is a flaw with the standard
\. I would be surprised if there are any use cases that rely on
\'s interaction with
evaluate as currently specified.