Re: Parsing text files with standard words
  Home FAQ Contact Sign in
comp.lang.forth only
 
Advanced search
POPULAR GROUPS

more...

 Up
Re: Parsing text files with standard words         

Group: comp.lang.forth · Group Profile
Author: Gerry
Date: Sep 16, 2008 00:44

On 16 Sep, 02:13, Josh Grams qualdan.com> wrote:
> Gerry wrote:
>>I think that EXECUTE-PARSING-FILE provides a partial solution...
>
>>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.
>
> 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.
>>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.
>
> I'll agree with you there, but I don't think that's an option in
> many systems anyway; see below.
>
>>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.
>
>>
>
>>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?
>
> The problem I see is that it 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?
>
> --Josh

This, while important, is a problem of implementation, not
concept. You're right about the stack needed (my system
maintains a linked list of input sources and so implementation
is easy). 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 - I wouldn't
like that sort of restriction, the rstack interferes with things
too much as it is.

Gerry
no comments
diggit! del.icio.us! reddit!