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.
>As a point of clarification, I am seeing the external parser as that part
>of perl that sees the user's script directly.
Mostly directly. There'll probably still be a level of indirection there,
since we need to take into account embedding programs that may do odd things.
> > > the external API needs to be flexible to handle perl in different
>writing
> > > styles
> >
> > This doesn't need to be the case; the external API may be
> > language-agnostic,
> > with the language rules set by internal calls.
>
>Then I'm misunderstanding the difference between external and internal.
Yup, I think so, but that's OK.
The internal API also doesn't need to care about a lot of language-level
stuff either. We need to take into account the fact that the rules on
what's a scalar (or a block start, or comment, or whatever) may be dynamic,
but the parse_token call is the parse_token call, regardless of the rules
in effect.
> If
>external touches the user's script, it can't separate itself from whatever
>particular syntax is currently in use.
Sure it can. It *must*, otherwise we'd need to rewrite parts of the parser
every time we added another language variant. I don't want to have to
rebuild perl just to use python mode. Yech.
>Maybe I'm going beyond the purpose of "API". Let me know if this is the
>case.
Yup. You've got the language rules mixed in with the API. Separate beast,
and one we're not dealing with here.
> > > perl6 perl5 python tclish
> > > \ \ / /
> > > \ \ / /
> > > ---------------------------
> > > READSTDIN and other commons
> > > full tree here
> > > ---------------------------
> > > |
> > > | <- required
> > > |
> > > ---------------------------
> > > OPCODES
> > > ---------------------------
> > > / / \ \
> > > / / \ \
> > > run store exe a
> > > bc bc binary java thingy
> >
> > I think you've just invented the compiler! :)
>
>I don't think so. In a compiler I don't believe that the intermediate step
>is there, and I've never seen any compiler accept multiple input semantics
>and multiple output (meaning binary, bytecode, java, c#))
Pretty much everyone's compiler does this at this point. Gcc's already been
mentioned, but Dec's compiler suites for VAX and Alpha do the same thing,
and from the literature it looks like other folks do it too. There's a
custom front end that produces an intermediate representation, and a common
IR->object optimizing back-end.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
