in reply to Perl 5 Compiler, Again!

1. perl -cw script.plx does nothing.

perlcc -B script.pl will compile to bytecode script.plc,

perl script.plc will execute the compiled script.

perl -c just stops after the CHECK phase.

2. system independent bytecode is hard, because threaded optrees looks different to not-threaded.

perl5 opcodes change from release to release, there's no discipline. p5 devs do not want to have bytecode discipline.

parrot was designed to have bytecode discipline originally (and be platform independent), but both of these goals were thrown away without discussion at v1.0. That's why I left the project in protest.

parrot's platform independent pbc format goal is still a goal in theory, but the tests were also disabled against my will around 1.0, so new bugs were introduced since the tests were disabled. code-smell.

3. perl had the -u switch to dump its code to a file, which could later be undumped to a single executable. To make this work would need about half a year, but I have no time for it yet.

Replies are listed 'Best First'.
Re^2: Perl 5 Compiler, Again!
by chromatic (Archbishop) on Aug 13, 2012 at 19:12 UTC
    ... both of these goals were thrown away without discussion at v1.0.

    Oh but they were discussed, my friend. I'm certainly no fan of the unnecessary breaking of bytecode compatibility willy-nilly with every release that goes on now, but the alternative of freezing PBC at Parrot 1.0 was certainly the worst of all of the options.

    PBC as it exists now is barely sufficient for Parrot, let alone Perl 6 or Perl 5.

[reply]
      On Parrot:

      I agree that technically freezing the names of ops with 1.0 was a small problem. But the number was low and new names could be easily added.

      There was never a public discussion about this policy change. Allison just went ahead and removed it, without any discussion. With my vehement disagreement, yes. But with no agreement from anybody else.

      If PBC now is not sufficient after the third rewrite what is still missing? When even the tests are disabled, and the packfile examples do not work?

[reply]
        But the number was low and new names could be easily added.

        Agreed. Adding new ops is not a problem. Alphabetizing the oplist and renumbering the ops was unnecessary.

        There was never a public discussion about this policy change.

        I remember several public discussions, at least in multiple #ps meetings.

        If PBC now is not sufficient after the third rewrite what is still missing?

        The last time I looked at PBC, it was still too tightly coupled to the internal layouts of various PMCs, especially the Sub PMC.

[reply]

In Section Seekers of Perl Wisdom