Gerry wrote:
> On 18 Sep, 12:26, Josh Grams
qualdan.com> wrote:>>
> 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.
OK, but I still don't see how the choosing EXECUTE-PARSING-FILE
instead of FILE-SOURCE affects the re-entrancy of anything. Well,
except that EXECUTE-PARSING-FILE has to be nestable, but that's no
big deal.
>> ... 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.
Ah. Now I'm with you. I was thinking of it in the context of
getting everyone to agree to do the same thing, which is rather
different. :)
>> : execute-parsing-file ( fileid xt -- )
>>>r swap file>input execute r>input ;
>>
>> 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...
>
> 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.
I haven't really used exceptions, but I assume the basic pattern
for resource deallocation etc. is to use CATCH CLEANUP THROW in
place of EXECUTE CLEANUP.
>> 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.
Yeah, and it allows you to nest input sources independently of
interpreters, which seems like a nice property to have.
--Josh
