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: [298]
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 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.
ruv
there is no similar extension to
\, which continues to discard the entire rest of the buffer.
According to the word included specification, it fills the input buffer with one line only. It means, the input buffer in this case contains not more than a single line, and the word 6.2.2535 \ "backslash" (CORE EXT) works correctly (there is no need for update this word in the FILE word set).
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.
A possible solution of this problem is to redefine "\" and evaluate the whole buffer in the editor. The new behavior for the word "\" is to skip the characters up to the next line terminator when the source-id is -1 and blk is 0 (otherwise no changes in behavior). This behavior is slightly not compliant, but in practice it does not cause problems in programs.
Cross-reference also ruv's post about exactly this problem.
Yes, my post's title is Portable line-oriented parsing, and the mentioned solution is provided in the "Comments in evaluated strings" section:
: is-input-string ( -- flag )
\ Return a flag: is the input source a string (being evaluated).
[defined] blk [if] blk @ 0<> if false exit then [then]
source-id -1 =
;
: source-following ( -- sd )
\ Return the parse area (a string).
\ NB: the returned string may contain a line-terminator sequence in any position.
source >in @ /string
;
: skip-source-line ( -- )
\ Discard a part of the parse area that belongs to the current line.
is-input-string 0= if ['] \ execute exit then
source-following over >r s\" \n" dup >r search if drop r@ then + rdrop
r> - >in +!
;
: \ ( -- )
\ This Backslash works as expected in evaluated strings too
skip-source-line
; immediate