Gerry
jackson9000.fsnet.co.uk> writes:[>>Gerry]
>Well yes, but the point I tried to make was that the caller of
>EXECUTE-PARSING-FILE loses control until the word executed
>(xyz-helper in your example) has completed, whereupon the file
>is closed. So the caller cannot process the file itself.
What kind of processing do you have in mind? What's wrong with doing
that processing in the word that you execute through
EXECUTE-PARSING-FILE?
>Oh, do they? Do you mean most systems return a fail flag when
>they could have worked (obeying the letter of the standard but
>not the spirit) or that they crash in some way?
Or throw. Yes, any of those.
>This is about the inadequacy of the QUERY spec. or the previous
>definition of QUERY being incompatible with the concept of nested
>input sources.
Yes. But will the specification of FILE-SOURCE and CLOSE-SOURCE be
better, and more importantly, good enough not to create problems.
>(Off topic) Shouldn't all the obsolescent words be deleted from
>Forth 200X for the same reason.
Probably.
>Are there many unanswered RFIs?
> Is the Forth 200X
>team addressing them?
Not at the moment. There are probably reasons why the Forth-94 TC has
not answered them, and we want to get some work done befor entering
this morass.
> Doesn't this mean that RESTORE-INPUT was
>inadequately specified in Forth 94. And shouldn't we do better
>in Forth 200X.
Yes. I believe that the reason why it was inadequately specified is
because it is hard to adequately specify such words in a way that
properly works with the nesting of INCLUDED, LOAD etc., except if you
make the additional word enforce the nesting, like EXECUTE-PARSING
does.
>>>When the
>>>file source reached the end or CLOSE-SOURCE was executed, the
>>>system would return to the original input source. In this simple
>>>example it would therefore behave much like INCLUDE-FILE. Are
>>>there any conceptual problems with this?
>>
>> So you propose an automatic CLOSE-SOURCE on end-of-file?
>
>Yes, why not?
The application would then continue reading, e.g., from the user input
device or from an enclosing file, even though the intention of the
programmer may have been different. I am suspicious of automagic.
>>>As this topic is perceived as a problem by more than one person
>>>perhaps we should consider standardising a solution, if it was
>>>the EXECUTE-PARSING-FILE solution I would prefer a better name.
>>
>> I would love to see an RfD from you on this, and I'm sure that the
>> naming issue will create a lot of discussion, as usual.
>
>OK I'll work one up, but I would prefer to do it via a FILE-
>SOURCE proposal with EXECUTE-PARSING-FILE as a fall-back.
If you do the RfD, it's your call. However, you will probably have a
much easier time if you go with EXECUTE-PARSING-FILE, for the
following reasons:
1) Much easier to specify: Fewer potential holes, and fewer choices
which can lead to discussions and make consensus harder to reach.
2) Existing practice: There is a widely-used system in which this
variant is implemented.
Even then, given the specialist nature of this feature, I don't expect
much interest.
- anton
