Dave Mitchell <[EMAIL PROTECTED]> wrote on 02/07/2004 06:46:50 PM:
> [ 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,
> 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?
I recall that there were at least two issues with the perly.[ch] that used
to ship with perl that were unacceptable for OS/390 prior to version
5.005 (or so) of perl: 1) they would not necessarily compile without
modification (IIRC cflags and or Makefile editing were called for)
2) they rendered a miniperl that did not seem to
understand its input correctly (among other problems miniperl was not
capable
of extracting Config.pm and the extension building that occurs would break
as
a result). What was done was to use perly.y as input and generate perly.c
and
perly.h on the EBCDIC platforms. The OS/390 or z/OS port used a yacc that
shipped
with the OS from IBM. The BS2000 port used a port of Bison to BS2000 for
the
same purpose. I've not really seen the perly.[ch] generated on BS2000 but
I
can tell you that back in the day when I was actively using perl on OS/390
that the generated perly.[ch] files seemed to have octal escapes used to
represent (mostly control?) characters in them. I suppose that was an
artifact of the way yacc worked on the IBM platform, it was certainly the
case that the IBM compiler compiled the locally generated perly.c file
much more easily (sans error or warning messages) than it did the byacc
ones that typically ship with perl.
> 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 cannot say as I am not that closely familiar with the details of
the BS2000 port.
> 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?
As far as OS/390 (now known as z/OS) is concerned I don't think that
there'd be much difference provided that extensive testing could be
carried out of proposed changes. In principle the BS2000 port could
benefit from the continued maintenance of perly.[ch] with bison rather
than byacc since it already uses an EBCDIC port of bison to generate
its own compatible perly.[ch] files. There too testing would be helpful.
Testing can be hard owing to limited availability of testing platforms
and/or volunteer time to conduct build tests.
Another thing to be wary of is the unusual manipulations that some other
ports may go through to render perly.c compilable. I know that the VMS
port applies a diff to replace perly.[ch] (the files vms/perly_[ch].vms
in the distribution) to render them acceptable to that platform's
picky compiler, and I suspect that Mac OS X may do something
similarly drastic. Of course both Mac OS and VMS are ASCII based and what
they do with the grammar/parser is for C compiler compatability not
coded character set interpretation.
Peter Prymmer
