Gerry
jackson9000.fsnet.co.uk> writes:>On 14 Sep, 22:21, an...@
mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>I think that EXECUTE-PARSING-FILE provides a partial solution,
>it is an ingenious way of achieving an equivalent to my solution
>2 in the original post but with the advantage of not having to
>insert the word to be executed at the start of the file. The
>reason I say it is a partial solution is because you have to
>define a word to parse and process the file, if another file is
>to be processed by nesting, that word may have to be called
>again so it may need to be re-entrant.
Yes. That's good practice anyway.
>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.
>These
>are fairly minor considerations but EXECUTE-PARSING-FILE does
>constrain a program design somewhat.
Certainly. But the advantage is that it works. For comparison, look
at words like SAVE-INPUT and RESTORE-INPUT, which may fail, and
probably fail most of the time in most systems.
>> 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.
> 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?
What happens if control falls back to the enclosing text interpreter
without either CLOSE-SOURCE or end-of-file happening?
>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).
You find the EXECUTE-PARSING implementation in
http://www.complang.tuwien.ac.at/forth/compat.zip
>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.
- anton
