>Are we talking about interprested or compiled parser ?
Compiled, in my opinion.
>1/ Please lets do some serious design before we go any further
Agreed.
>3/ I can't agree on the name. Inline::Yacc should be an interface to Yacc
>not the (gentle) monster you describe
I have no problem with that, it's just a name. If "Inline::Yacc" should
be reserved for inlining pure yacc it sounds ok.
The only remaining question is *which* namespace or naming scheme to
use for such combined solutions which do not address exactly *one*
existing language. Inline::Multiple::Yacc? But this would still mention
one language only ...
I think we should just find a convention everyone can live with, which
should be flexible enough to make future (multi language) projects fit
in.
>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 ...
>I will look at 'lemon' another parser generator (I never used it before)
>that looks promissing.
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.
>Inline::Pbyacc ...
I hope to have a closer look at your examples soon ...
Greetings
Jochen
