> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Monday, December 10, 2001 10:34 PM
> To: [EMAIL PROTECTED]; Nadim Khemir
> Subject: RE: Inline::Yacc and other
>
....
> >1/ Please lets do some serious design before we go any further
> Agreed.
When do we get to see the first ideas
>
> >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.
>
> Back in my C days I arranged nested yacc parser calls by saving the
> global values on a stack. Of course this only works for sequential
> calls ...
Exactly what we do not want to do isn't it ?
>
> >I will look at 'lemon' another parser generator (I never
> used it before)
> I read a short description today and remember they said "while with
> yacc/bison the parser calls the tokenizer, with lemon the tokenizer
> calls the parser". So this is a different approach (while yacc and
> bison are basically the same) - which might as well be worth to be
> implemented, but it would be great if we could process yacc style
> grammars as well.
>
There is actualy no diffrence between the lexer calling the parser or the
opposite.
I agree that yacc should also be present in our toolbox, then ,when I think
about it, why should it?
I need multiple parser, do I need to wrestle whith yacc for that?
> >Inline::Pbyacc ...
> I hope to have a closer look at your examples soon ...
Things are getting better. I have a working Inline::Pbyacc but It is
completely interpreted and even the lexer is interpreted. There are 3
versions of Pbyacc-Byacc -P around and I, of course, manage to have all
installed on my machine. After some cleaning, I got the first Inline::Pbyacc
to work.
There are few negative points with PByacc:
-interpreted
-uses Fstream module instead of IO
-no documentation
-no home to get the latest version
-placement of generated files is heratic
Good point : it ALL perl
I will direct my efforts toward Inline::PByacc this week. If someone knows
where the home of Pbyacc I could submit a patch to use IO instead for
Fstream.
Inline::Grammar::C could be easily re-written to use Pbyacc.
For those that follow this dicussion without knowing why we want faster
parsers and compilers here is a little example:
******************* braindead perl code run on a 5 MB file
while(<>)
{
}
nadim@NADIMHOME /d/Dev/Projects/test
$ time perl plexer_test.pl < "D:\Dev\Projects\test\tmon.out"
real 0m2.553s
user 0m0.010s
sys 0m0.020s
******************* compiled lexer run on a 5 MB file
use Inline Flex =><<'END_FLEX' ;
%option noyywrap
%option prefix="Default"
exp (([eE][0-9]+)?)
fltsuf (([lL]|[fF])?)
intsuf (([lL]?[uU]?)|([uU]?[lL]?))
%%
%{
// regexes and action code
%}
[0-9]+[eE][0-9]+{fltsuf} |
[0-9]*\.[0-9]+{exp}{fltsuf} |
[0-9]+\.[0-9]*{exp}{fltsuf} { ; /* float */}
0 { ; /* zero */}
0[xX][a-fA-F0-9]+{intsuf} { ; /* hexadecimal */}
[1-9][0-9]*{intsuf} { ; /* integer */}
0[0-7]*{intsuf} { ; /* octal */}
[a-z_A-Z][a-z_A-Z0-9]+ { ; /* identifier */}
\\ { ; /* escaped_char */}
\t { ; /* tabulation */}
\ + { ; /* spaces */}
[A-Za-z_] { ; /* single_character */}
.. { ; /* separator */}
\n|\r\n { ; /* new_line */}
%{
%}
%%
END_FLEX
yylex() ;
nadim@NADIMHOME /d/Dev/Projects/test
$ time perl lexer_test.pl < "D:\Dev\Projects\test\tmon.out"
real 0m0.651s
user 0m0.020s
sys 0m0.010s
What about a lexer (12 diffrent tokens recognized) that is 4 times faster
than a no op perl script.
I guess Jochen is right, we want compiled parsers even if we must shuffle
data forth and back.
Nadim
