Front page | perl.perl6.internals.api.parser |
Postings from November 2000
Err, this seems a little too Swiss Army Knife. This reads like a utility function. (i.e. A function that handles the most common scenerio.) Shouldn't a set of lower level visible API be visible? One that seems to pop out at me is some way of actually parsing a piece of code and ending up with a handle on a syntax tree. And ways of adding and removing these pieces. These are abstract functions that would be needed on the interior of the parser, but a bottom up approach may be more appropriate here. I also like the suggestion that rather than supply flags, we should follow the lead and supply a Perl* something that would return an appropriate bunch of text to the parser. <chaim> >>>>> "DS" == Dan Sugalski <dan@sidhe.org> writes: DS> While I'm not sure of the structure of the internals of the parsing piece DS> of perl at the moment (and, unfortunately, language parsers aren't one of DS> my strong points), I am reasonably certain of the interface we'll present DS> to the rest of the world and the other pieces of perl. So... comments? DS> --------------- DS> int perl6_parse(PerlInterp *interp, DS> void *source, DS> int flags, DS> void *extra_pointer); DS> The first parameter is a pointer to a perl interpreter--this'll be used if DS> any code needs to be executed, as well as being a repository for any DS> variables that compiled code may set. (Standard stash stuff) The syntax DS> tree the parser generates will also be embedded here. (One fewer parameter DS> to deal with, and one fewer thing for an embedding program to track) DS> The second parameter is a pointer to the source to be compiled. This is DS> generally a char pointer, but it may also be a FILE * or a pointer to a DS> function that returns a char pointer. DS> The third parameter is the flags parameter, and it's optional. If omitted DS> or set to PERL_CHAR_SOURCE, the second parameter is treated as a standard DS> null-terminated string. If set to PERL_COUNTED_SOURCE, the second parameter DS> is treated as if it points to a stream of bytes, where the first four are DS> the length of the source to be read followed by the source. If set to DS> PERL_FILE_SOURCE it's assumed to be a FILE *, while if set to DS> PERL_GENERATED_SOURCE it's assumed to be a pointer to a function that DS> returns a char pointer. If it's OR'd with PERL_UTF8_SOURCE then the stream DS> is assumed to be in UTF-8 format instead of platform native. DS> The fourth parameter is only used if the flags are set to DS> PERL_GENERATED_SOURCE, in which case it is passed back to the function DS> whose pointer we got as parameter two. DS> Dan DS> --------------------------------------"it's like this"------------------- DS> Dan Sugalski even samurai DS> dan@sidhe.org have teddy bears and even DS> teddy bears get drunk -- Chaim Frenkel Nonlinear Knowledge, Inc. chaimf@pobox.com +1-718-236-0183Thread Previous | Thread Next