Hi folks, and sorry about the delay. (And extended silence)
This list is here to design the internal and external API for the
parser/tokenizer/lexer part of perl. Basically we need two bits:
1) The API presented to the rest of the world. This is likely one call,
though if folks want to split it out for external and internal use, that's
fine.
2) The internal API. These are the places where hooks can be installed, or
bits of the parser that those hooks can call back into the parser. (Or
parser/lexer/tokenizer utility routines the hooks can call)
The general rules of the game are:
* The parser will be written mostly in perl, so you have regexes and such
to work with
* The parser will have an active interpreter structure handy
* The parser needs to be reentrant
* The ultimate output of the parser will be a syntax tree
* It's OK to store stuff in the interpreter structure. (Which will have the
full perl global variable stash in it)
* The keywords the parser uses may be changed on the fly, and the parser
needs to handle this.
* It's possible that the whole set of parsing rules may change on the fly,
so don't get hung up on constants like "{"--stick to symbolic things like
start_scope instead
It's distinctly possible the deadline will need to be extended, or that the
resulting PDD will be really simple. Either's OK.
If someone else wants to hold the WG chair that's just fine with me. I will
add that parsing/lexing/tokenizing in general, and in the way perl needs
it, is *not* anywhere near my area of expertise. While I can specify the
external and inter-module interface just fine, the actual internals of the
parser aren't my thing. (Not that it's necessary for handling the group
chair, but if there's someone with both interest and expertise...)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
