>>Also it precludes a
>>design where an application opens a file source and then returns
>>to whatever called it to parse and process the file.
>
> No. EXECUTE-PARSING-FILE takes a file-id, so your application would
> open the file, then pass the resultin file-id to its caller, which
> would then call EXECUTE-PARSING-FILE.
>
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.
>>These
>>are fairly minor considerations but EXECUTE-PARSING-FILE does
>>constrain a program design somewhat.
>
> Certainly. But the advantage is that it works.
So does FILE-SOURCE in my system
> For comparison, look
> at words like SAVE-INPUT and RESTORE-INPUT, which may fail, and
> probably fail most of the time in most systems.
>
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?
>>> Until Jonah Thomas came up with the glorious idea that lead to
>>> EXECUTE-PARSING and EXECUTE-PARSING-FILE, I was also thinking along
>>> similar lines. However, the problem with such words is that they do
>>> not fit in the usual nesting of INCLUDED, EVALUATE and LOAD.
>
>>I don't understand why you say this.
This is about the inadequacy of the QUERY spec. or the previous
definition of QUERY being incompatible with the concept of nested
input sources. Well given that QUERY was flagged as obsolescent
in Forth 94 I propose that these problems be eliminated by
deleting QUERY from Forth 200X. Surely 14 years is long enough
for systems to have removed their reliance on QUERY.
(Off topic) Shouldn't all the obsolescent words be deleted from
Forth 200X for the same reason. After all, part of maintaining
standards is removal of things that have outlived their
usefulness. Are there many unanswered RFIs? Is the Forth 200X
team addressing them?
er this RFI may not have been answered but the proposal in the
RFI seems to have been partially adopted e.g. see
11.3.1.2. But
not for RESTORE-INPUT so I take your point. This seems to be
a gripe about GForth
0.3.0's implementation that raised an
exception instead of reporting a failure via the return value,
yet met the standard. Doesn't this mean that RESTORE-INPUT was
inadequately specified in Forth 94. And shouldn't we do better
in Forth 200X.
This RFI requests that SAVE-INPUT and RESTORE-INPUT be less
restrictive. This is arguable.
If SAVE-INPUT and RESTORE-INPUT are inadequate for INCLUDED and
friends then they will be equally inadequate for FILE-SOURCE
(and for EXECUTE-PARSING-FILE ??). It's a reason to improve the
specification of SAVE-INPUT and RESTORE-INPUT not to forbid the
addition of words that they may be relevant to.
>
>> As FILE-SOURCE simply
>>stacks another input source and switches to a new input source,
>>I see no reason, in principle, why it couldn't fit into the
>>scheme of things. To take a simple example suppose the system is
>>in interpret mode and the user types in s" filename" FILE-
>>SOURCE. Having executed FILE-SOURCE control returns to the text
>>interpreter which could simply use the stream attached to the
>>new input source (of course this assumes that the different
>>input sources use the same text interpreter which, in practice
>>for a given system, may not be true, but I'm talking in
>>principle). While interpreting the file there is no reason why
>>another file could not be INCLUDED or a string EVALUATEd, when
>>they finished the file source could be returned to. 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?
>
> What happens if control falls back to the enclosing text interpreter
> without either CLOSE-SOURCE or end-of-file happening?
Given my previous assumption that the same text interpreter can
handle all input sources, I would expect it to start
interpreting text from the position reached in the file. If this
is valid Forth - fine, if not something will fail. I'm assuming
here that the situation has arisen by programmer choice (or
error) and not via an exception which should cause input sources
to be closed down anyway.
>
>>I can't see a way to define FILE-SOURCE using ANS Forth only,
>>presumably this is also true for EXECUTE-PARSING-FILE?
>
> One can implement EXECUTE-PARSING by copying the string and prepending
> X, and setting up the interpreter such that X executes the actual word
> we are interested in. A similar technique could be used for
> EXECUTE-PARSING-FILE, but is not very practical and runs into other
> problems (how to get a temporary file name for the copy of the file).
>
I never considered copying the whole file, yes that works.
[...]
>>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.
Gerry
