Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 21, 2000 at 10:37:23AM +0000, David Grove wrote:
> > I'm not sure that it's possible to do this, or disirable. If Larry
wants
> > Perl to use different modes, creoles, or ways of interpreting or
> > understanding the "perl" language, then we have to let the parser
have a
> > bit more information.
>
> Yes, but these don't have to be external level calls.
>
> > As a point of clarification, I am seeing the external parser as that
part
> > of perl that sees the user's script directly.
>
> Likewise.
>
> This is why the "creole" rulesets are *not* external calls.
>
> Syntax definitions, in the form of Perl programs or pragmata, will have
to
> go
> through two stages before they can be used. First, they have to be
parsed
> as
> Perl code. This is a call to the external API of the parser.
>
> Once this is done, the resulting op tree must be processed so that it
can
> be
> turned into a data structure (representing the grammar) which can be
> understood by the parser.
Actually, I think I'm getting it. In my model, what you guys are calling
"internal API" is basically what I'm leaving in that intermediate area,
kinda sorta? The parser that I'm talking about is what receives the perl
code.
So:
1. The External API has a pure syntax that has already gone through a
toplevel process to produce something identifiable to the "External API".
2. There remains a separation between the internal API and the external
api.
3. I'm attempting to call that toplevel parser the "internal api", and
need a word for it.
I'd submit that, since the creole parser needs to speak to the internal
API, it should become part of the spec for the entire parser.
Does it make sense that the creole parser be on the top of that chart I
made, and that the External API ends up what's in the middle?
p
