Dave Mitchell <[EMAIL PROTECTED]> writes:
>[ Please CC me on any replies as I'm not subscribed here ]
>
>Over on perl5-porters I've put forward a proposal to replace byacc with
>bison as the standard tool for generating perly.[ch] from perly.y,
Last time that came up the issue was that GNU parser template was GPL,
which meant that perl would be GPL only.
Of course there are other bison(s) now which have less restrictive license.
>and someone suggested that there may be EBCDIC issues and that I should
>ask on this list. Having rummaged around in README.bs20000, which
>seemed to be the only README that mentioned yacc/bison, I now have the
>following questions.
>
>1. Why is the perly.[ch] that is already bunded with Perl not suitable; ie
>why do you have regenerate it yourselves?
The usual problems with EBCDIC are:
A. Many common chars have high bit set
B. 'A'..'Z' and 'a'..'z' have gaps in and some of those gaps
contain non-alpha symbols.
IIRC byacc parser suffered from (A).
It was using signed char for terminal symbols at literals
but expecting them to be positive, as -ve values were used for special
purposes.
>
>2. The README file says that the perly.y file should be prefixed with
>%pure_parser to generate, well, a pure parser. Is there any particular
>reason why this necessary?
I saves perl having to grope in generated parser's guts to save state
if it invokes parser recursively. It also makes the #define hackery
a bit more robust.
>
>3. Would moving the main Perl distribution over to a bison-generated
>perly.c help or hinder you, and do you have and gotchas you need to warn
>me about?
Probably help.
>
>Thanks,
>
>Dave.
