Gerry wrote:
> On 16 Sep, 02:13, Josh Grams
qualdan.com> wrote:
>>> But...if you want to process a nested file, wouldn't the code need
>> to be re-entrant even if you were using FILE-SOURCE/CLOSE-SOURCE?
>
> Not necessarily, we're discussing parsing and processing a file
> in a particular format. The nested file could be a part of that
> format, processed by a particular word called to deal with it
> after FILE-SOURCE was executed.
Hrm. Maybe we're talking about different things -- here's what
I'm picturing. You have code to process a file in a particular
format. While you're doing this processing, you need to process
a nested file, with the same code, and then return to where you
left off. As I see it, regardless of the method used to nest and
restore the input source, the code doing the processing needs to
be able to nest as well: any per-file global state must be saved
and restored with each call. Though maybe that's not what you
mean by re-entrant?
>> The problem I see is that FILE-SOURCE requires a separate stack
>> for input sources. In some systems, EVALUATE/INCLUDE/etc. save
>> the old input source specification by pushing it onto the
>> rstack, in which case there is no way for any other word to
>> find and restore it.
>>
>> Or am I missing something?
>
> This, while important, is a problem of implementation, not
> concept.
But... it means that FILE-SOURCE and CLOSE-SOURCE can't be
implemented without restrictions on some systems. To me, that
represents a problem with the concept; it conflicts with some
existing implementations.
> Systems such as you describe presumably rely on the input source
> spec being on top of the rstack when the end of an included file
> is reached. So anyone using FILE-SOURCE and CLOSE-SOURCE would
> have to ensure they were used in the same definition with
> balanced >R R> pairs between them.
Yes, which is exactly the restriction that EXECUTE-PARSING-FILE
embodies. It looks something like this:
: execute-parsing-file ( fileid xt -- )
input>r swap file>input execute r>input ;
: read-loop begin refill while interpret repeat ;
: included ( fileid -- ) ['] read-loop execute-parsing-file ;
Without knowing how many levels of nesting are used in the word
which is processing the input, there's no way of knowing where on
the rstack the old input spec is, and thus no way to implement
FILE-SOURCE such that you can return to the caller and let it
interpret and close the new file. At least that I see.
It may well be better to have a separate input source stack. But
some systems don't have one, so it would probably be easier to get
agreement on EXECUTE-PARSING-FILE than FILE-SOURCE/CLOSE-SOURCE.
--Josh
