Hello,
>I get the feeling this is getting quite serious. If we are going to
>cooperate on this, I propose that we do it seriously to avoid having 3
>people doing the same thing in incompatible ways.
I completely agree with you. Having three implementations confuses
people and may cause a lot of problems, besides wasting time we could
use better to implement a good solution earlier.
More, several people involved that far (including myself) are very
interested but quite busy. Building a team might accelerate things.
>What is it we want to do and with what ?
The following (late evening) thoughts are just suggestions.
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.
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 ...").
I'm not sure if the time we win by using a C parser will be compensated
by the additional overhead of value passing (such a general way), but I
think it's really worth the trial. Finally, inlining a grammar should
result in an acceleration, of course.
The list of necessary interface conventions is most probably
incomplete. Perhaps we should try to collect more, or/and to define a
"base set" of interfaces we want to start with.
Maybe we can start with a subset, let's say by supporting C/C/C
(parser/actions/lexer) grammars first. C/Perl/C and C/Perl/Perl might
be the next steps. Then we could implement Parse::Yapp compatibility.
And so on ...
>Inline::Bison
>Inline::Byacc
I'm not sure if Inline::Yacc and Inline::Bison really need to be
separate modules. At least bison has a yacc compatibility mode if I
remember right.
Byacc, as I remember, uses a different approach. But I assume there are
parts that could be used both by Inline::Byacc and
Inline::{Yacc,Bison}.
Jochen
