|
|
 Up |
|
|
  |
Author: GerryGerry Date: Sep 15, 2008 05:17
>>I've seen discussions on this deficiency (IMHO at least) in the
>>ANS standard in the c.l.f archives but they all seem rather
>>inconclusive. The fundamental problem is that all words, such as
>>INCLUDED, that change the input source also invoke the Forth
>>text interpreter and there is no standard way of overcoming
>>this.
>
> Yes. To overcome this problem, Gforth provides
>
> |execute-parsing-file ( i*x fileid xt - j*x )
> | Make fileid the current input source, execute xt `( i*x -- j*x )',
> |then restore the previous input source.
>
> I find that pretty conclusive.
>
|
| Show full article (4.14Kb) |
|
| | 13 Comments |
|
|
Author: Josh GramsJosh Grams Date: Sep 15, 2008 18:13
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?
>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.
|
| Show full article (1.47Kb) |
|
| | no comments |
|
|
Author: GerryGerry 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...
|
| Show full article (2.38Kb) |
| no comments |
|
|
Author: Anton ErtlAnton Ertl Date: Sep 17, 2008 13:32
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.
|
| Show full article (4.23Kb) |
| no comments |
|
|
Author: Josh GramsJosh Grams Date: Sep 18, 2008 04:26
Gerry wrote:
> On 16 Sep, 02:13, Josh Grams qualdan.com> wrote:
>>> 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.
Hrm. Maybe we're talking about different things -- here's what
I'm picturing. You have code to process a file in a particular
format. While you're doing this processing, you need to process
a nested file, with the same code, and then return to where you
left off. As I see it, regardless of the method used to nest and
restore the input source, the code doing the processing needs to
be able to nest as well: any per-file global state must be saved
and restored with each call. Though maybe that's not what you
mean by re-entrant?
|
| Show full article (2.70Kb) |
| no comments |
|
|
Author: GerryGerry Date: Sep 18, 2008 12:55
>>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.
|
| Show full article (5.99Kb) |
| no comments |
|
|
Author: cooscoos Date: Sep 18, 2008 13:11
Op Thu, 18 Sep 2008 12:55:58 -0700 (PDT) schreef Gerry:
>>>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.
>
|
| Show full article (0.97Kb) |
| no comments |
|
|
Author: GerryGerry Date: Sep 18, 2008 13:36
On 18 Sep, 12:26, Josh Grams qualdan.com> wrote:> Gerry wrote:
>> On 16 Sep, 02:13, Josh Grams qualdan.com> wrote:>
>>> 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.
>
> Hrm. Maybe we're talking about different things -- here's what
> I'm picturing. You have code to process a file in a particular
> format. While you're doing this processing, you need to process
> a nested file, with the same code,
|
| Show full article (4.03Kb) |
| no comments |
|
|
Author: GerryGerry Date: Sep 18, 2008 13:47
On 18 Sep, 21:11, coos wrote:
> Op Thu, 18 Sep 2008 12:55:58 -0700 (PDT) schreef Gerry:
>
>
>
>
>> [...]
>
>>>>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 ...
|
| Show full article (1.34Kb) |
| no comments |
|
|
|
|
|
Author: Josh GramsJosh Grams Date: Sep 18, 2008 17:56
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.
|
| Show full article (2.08Kb) |
| no comments |
|
|
|
|
