At 12:46 PM 11/21/00 +0000, David Grove wrote:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> > At 10:37 AM 11/21/00 +0000, David Grove wrote:
> > >Thanks for the clarifications, Simon.
> > >
> > >Simon Cozens <[EMAIL PROTECTED]> wrote:
> > >If we were simply feeding it perl with a single syntax, we could get
>away
> > >with a "one call" scheme. But since we're dealing with almost
>certainly
> > >mutually exclusive syntax and semantics, it probably needs more
> > >information.
> >
> > But we are. The call is probably going to be something like:
> >
> > status = parse_perl(perl_interpreter *my_interp,
> > char *script,
> > struct HIR *end_result,
> > long flags);
> >
> > the fact that the script has a "use pythonish;" in it is entirely
> > irrelevant--the program calls into the parser, which returns a status
>and
> > possibly a parsed representation of the program. The parser gets to
>deal
> > with all the grotty details.
>
>What form is this intermediary parsed representation in? API, right? Then
>I need to clarify that when I say bytecode, I've meant whatever this
>intermediary parsed representation is, be that pure perl, API, or
>otherwise.
Okay, you're more confused here than I though.
API = Application Program Interface (More or less. Something like that, at
least). Basically the list of function calls and their parameters, perhaps
with a set of rules around what can be called when. It's perfectly
appropriate to have some things left as magic cookies at this point, like
the syntax tree format, though their general characteristics can be specified.
It might well be that we want to define the format of the syntax tree now
as well, though I'd have preferred to leave that for a little later.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
