At 10:18 AM 11/21/00 -0800, Benjamin Stuhl 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);
>
>Well, it would (IMHO) make more sense to have
>perl6_parse_script (I do tend to follow
>{subsystem,verb,object} naming...)
Or Perl$parse_script, but that's a matter of taste, I suppose. :)
> take a PerlIO*, so that
>it is completely transparent parsing from a file or a
>string. This gets almost into embedding issues, though (how
>much of a libc does perl6 really need? perl5 now carries
>large chunks of one around with it).
I'm not sure we want a PerlIO* passed in, for embedding reasons. I can see
embedding programs wanting to pass in a pointer to a string with the whole
script, a filehandle of some sort, or a pointer to a function that produces
the script in really odd cases. (Possibly with a second pointer in that
case to misc data)
Maybe something like:
perl_parse(interp *interp,
void *script,
void *extra,
syntree *parsed_perl,
int flags);
where the flags arg indicates what sort of thing the script pointer is. Or
perhaps:
perl_parse(interp *interp,
void *script,
syntree *parsed_perl,
int flags,
void *extra);
with the extra pointer and the flags argument vararg'd into optionality.
(Defaulting to NULL and 0, respectively)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
