http://www.perlmonks.org?node_id=987185


in reply to Re: Perl 5 Compiler, Again!
in thread Perl 5 Compiler, Again!

... 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.

Replies are listed 'Best First'.
Re^3: Perl 5 Compiler, Again!
by rurban (Scribe) on Sep 20, 2012 at 23:14 UTC
    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