On 18 Sep, 12:26, Josh Grams
qualdan.com> wrote:> 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,
This is where we differ. The sort of thing I was thinking of is
exemplified in an XML file where use of an external style sheet
can be specified. A cascaded style sheet has a totally different
format to XML and is likely to be processed by different code. I
agree with you in the scenario you present.
> 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?
No, I agree with you here.
>
>>> 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.
I take your point, but it does seem to me a bit like the tail
wagging the dog. I'd rather see the ideas thrashed out even if
adoption proves to be unpopular or impractical or if a
compromise has to be reached.
>
>> 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 -- )
>>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.
If there is no way to get at an input source spec on the rstack,
how do these systems close down these input sources in the event
of an exception? This is required by the ANS Forth standard.
But you are right, such a system can't return to a caller
without losing the input source information on the rstack, at
least not without a lot of trouble.
>
> It may well be better to have a separate input source stack. But
> some systems don't have one,
Provision of one is not difficult, a linked list of input source
specs in dataspace suffices and is easy to implement.
> so it would probably be easier to get
> agreement on EXECUTE-PARSING-FILE than FILE-SOURCE/CLOSE-SOURCE.
You may be right, Anton Ertl has stated that he'd like to see
an Rfd on the subject. I think I'll try writing one and perhaps we'll
see.
Gerry
