Hi, I changed my mail program so the original mail is tagged properly,I hope this mail will be easier to follow.
> -----Original Message----- revamped by nadim > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Monday, December 10, 2001 2:06 AM > If possible, I vote for greatest flexibility. This does not mean > everything of the following should be implemented necessarily and > immediately but a design that makes it possible to implement it. My > wishlist includes > > (1) Grammars written in yacc with > (2) actions written in any inlinable language > including Perl, with a choice for every action, and > (3) lexers and other functions yacc allows to define > written in any inlinable language. > (4) For convenience of Perl programmers, grammar > comments should be accepted both the yacc and the > Perl way. > (5) I hope that Parse::Yapp grammars can > be used more or less unmodified. See > my previous mail. Are we talking about interprested or compiled parser ? > > When I say "yacc" it includes "bison" and other "dialects", of course. > (Byacc might be special, I only read of it years ago.) > > This requires generic interfaces to pass values back and forth between > languages if necessary (but not until C space is left). It requires > conventions about how to access yaccs stack, and calling conventions > for every definable function like the error messenger and the lexer > (besides pure C and Perl lexers, Inline::Flex and Parse::Lex made > lexers spring into mind here). We might have to define restrictions > ("unless you write C actions as in traditional yacc, (with this > version) you cannot ..."). > Wow, wow. It sound all fine to me except : 1/ Please lets do some serious design before we go any further 2/ Does the next version of Inline make this easier ? 3/ I can't agree on the name. Inline::Yacc should be an interface to Yacc not the (gentle) monster you describe > I'm not sure if the time we win by using a C parser will be > compensated by the additional overhead of value passing True, I think we will win by using a C based lexer anyhow. But if the lexer is compiled and does not pass to many values back to perl I think I could be MUCH faster. > > Jochen Here are the results of this week-end work. *******Inline::Flex Inline::Flex is documented. What remains to be done is test it (volunteers raise your hands). Missing is the possibility to give an in stream to the lexer. (reads from the console right now) I also need to study what happends if one has multiple lexers running at the same time. *******Inline::Bison Inline::Bison I got link errors that I could trace to perly.h, embed.h, .. we can't have a Yacc (the program) or bison parser used multiple times (this is a limitation one might get around) that has much to do with naming. I will look at 'lemon' another parser generator (I never used it before) that looks promissing. *******Inline::Pbyacc Inline::Pbyacc exists, this might be the solution we are looking for in the nearest time. PByacc generates parsers in perl. this allows use to write rules in perl. The disadvantage is that the parser is interpreted. There is no lexer generators giving us perl code but we have Inline::Flex. What I have now, looks like this package PbyaccTest ; # Nadim Khemir use strict ; use warnings ; # Extend current package with a parser and a lexer # ** parser ** my $yylval = 111 ; # C code doesn't need to check if this variable exists use Inline Pbyacc =><<'PBYACC' ; %token INTEGER FLOAT IDENT %left '+' '-' .... stmt: expr terminator { print $1, $P = $1; # this is perl} ; .... PBYACC # ** lexer ** use Inline Flex => Config => FLEX_COMMAND_LINE => 'flex -L -f -8 -oOUTPUT_FILE INPUT_FILE' ; use Inline Flex =><<'END_FLEX' ; .... #define INTEGER 257 .... [0-9]+\.[0-9]*{exp}{fltsuf} { // use perl api to set yylval SV * perl_yylval = get_sv("PbyaccTest::yylval", FALSE) ; sv_setnv(perl_yylval, atof(yytext)) ; return(FLOAT) ; } .... END_FLEX # test 1 yylex() ; print __PACKAGE__, "\n" ; print "$PbyaccTest::yylval\n" ; print "$yylval\n" ; # test 2 sub PrintError {print @_, "\n"} ; sub PrintDebug {print @_, "\n"} ; my $parser = new PbyaccTest(\&yylex, \&PrintError, \&PrintDebug) ; while(1) { # yyparse calls yylex stub $parser->yyparse() ; } 1 ; So we have a yacc style parser with rules in perl (I doesnt sound impossible to have the possibility to inline here). The lexer is written in C. Test 1 seems to work but I get the stranges error ever: print __PACKAGE__, "\n" ; gives => PbyaccTest print "$PbyaccTest::yylval\n" ; gives => the value I give to the lexer (123 for example) print "$yylval\n" ; gives => 111 ; I think those scalars are the same but not perl ??? Even better if I eliminate the line "my $yylval = 111 ;" perl crashes as I use a NULL pointer in the lexer. (as it should) Can someone explain. Test 2 starts but I get an error due, I think, to my little kowledge of how to use the generated parser. The example I got was with non object oriented lexers so I repeatedly got errors till I ,luckily, noticed a 'new' function in the generated code. Pbyacc is a gore when it come to where the files are generated and what they are called (Regex to my rescue !!) Anyhow, this looks promissing and I hope to have something working quite soon. ******Inline::Yacc (jochens module) Sorry I didnt have enough time but as soon as Inline::Pbyacc works I'll get onto it ****** nm 'nm' works fine on windows, we get the name of the symboles in the module. What are we going to do with them ? Is it acceptable (I think yes) to first compile the module to have the possibility to extract the symboles. Find the function declarations with the help of the extracted symboles and some simple Regular exp (fast). Generate an Xs, compile again. There must be a way to generate more information: defintion line, arguments and return values. Any idea? Nadim.
