At 07:36 AM 11/21/00 -0500, David Grove wrote:
>However, one thing is seriously lacking in this theory... if the parser is
>perl, how does the perl parse? (Sort of a woodchuck chucking wood type of
>thing.) Somehow, the external parser API thingy has to know enough perl
>(through the chosen language) to be able to handle the parsing.
Nope. We do it in two phases. The end result will not actually parse perl
code to build the parser (we'll provide bytecode for that) but to start we
can run the parser through perl 5 to get a syntax tree until the perl 6
engine's capable of doing it itself.
>[GOALS]
>EXTERNAL API:
>1. Provide a multi-creole interface as a middleman between the programmer
>and his language.
>2. Provide a common interface (mapping) between the creole and the
>internal API.
>3. Write it in Perl.
Yup.
>INTERNAL API:
>1. Expose the internal API to be used by the external API for use by the
>creoles.
>2. Provide a common interface (mapping) between the internal API and the
>underlying language.
>3. Write it in ...
Yup.
>4. Provide a mapping between the internal bytecodes and either internal
>Perl or translation API (the C# and Java thingies)
Nope. The syntax-tree to bytecode converter's a separate piece.
> > The general rules of the game are:
> >
> > * The parser will be written mostly in perl, so you have regexes and
>such
> > to work with
>
>To quote my perl elders, whatever can be done without regexen should be
>done with index() (within limits, since some regexen can be quite
>optimized).
No, not really. regexes are generally easier to comprehend than their index
couterparts, and often faster. (There's a lot of code that needs to go into
backtracking...) While index might be better sometimes we can't force folks
to use it. Almost all of perl is up for grabs.
>The parser API needs to know both regexen and index() in order to work.
The parser will have a fully-functional interpreter to work with. All of
perl will likely be there for it. (Modules and threads might not, but
that's still up in the air)
> > * The parser will have an active interpreter structure handy
>
>Is this the perl that parses the perl?
Yup. In fact we might have two--the interpreter structure for the
interpreter running the parser, and the structure for the end-result parsed
program. Or we might just use one and squirrel all the interpreter bits in
a private (and deletable) namespace somewhere.
>Yeah, I'm going over this in order.
>Maybe I should have read the whole thing first.
Nah, y'think? :-P
> > * The parser needs to be reentrant
>
>No clue what this means. I need this defined in context.
The parser needs to be able to call back into itself without screwing
things up. Very little global state, in other words.
> > * The ultimate output of the parser will be a syntax tree
>
>I think I said that.
More or less. Perl will probably have two different intermediate
representations, the parsed syntax tree and bytecode. The parser only spits
out the syntax tree.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
