11.6.1.1718 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.
See:
Rationale:
filename" INCLUDED ...
Testing:
ContributeContributions
NickMessenger
[298] 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 ( or \. I'm actually not really sure how it could be fixed. Other than:
I would propose a new section 11.6.2.2535 so that, when blk is 0, \ discards "the rest of the line," where that's defined to be the same as in included here.
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.
NickMessengerNew Version
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 ( or \. I'm actually not really sure how it could be fixed. Other than:
I would propose a new section 11.6.2.2535 so that, when blk is 0, \ discards "the rest of the line," where that's defined to be the same as in included here.
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.
Cross-reference also ruv's post about exactly this problem.
NickMessenger
I see now this issue was discussed at length on PARSE. Please pardon the noise I have some reading to do.