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


in reply to Re: Perl 5 Optimizing Compiler, Part 2
in thread Perl 5 Optimizing Compiler, Part 2

Ed, I'm no expert but I think you may be a bit confused. Your "Perl 5 Compiler, Again!" thread definitely did NOT prove that the "compiler topic is near impossible to solve". That thread was basically just one tit-for-tat between chromatic and Reini Urban, who are on opposite sides of the fence on this particular issue, and who are apparently also not the best of friends. Nothing solid can be deduced from that thread.

The bytecode issue is only one aspect of the complicated optimizing problem. We may be able to produce a Perl 5 optimizing compiler without use of the Perl bytecode system at all. On the other hand, bytecode may turn out to be a critical component in optimizing, only time will tell.

Perl 6 seems to be a pipe dream. Perl 5 seems to be stabilized and mostly in maintenance mode. I'm not interested in creating Perl 7, since Perl 6 needs to happen first, if ever. I'm interested in compiling & optimizing Perl 5, and this is what I will achieve. :-)

  • Comment on Re^2: Perl 5 Optimizing Compiler, Part 2

Replies are listed 'Best First'.
Re^3: Perl 5 Optimizing Compiler, Part 2
by chromatic (Archbishop) on Aug 22, 2012 at 16:41 UTC
    Nothing solid can be deduced from that thread.

    Indeed, and yet:

    That thread was basically just one tit-for-tat between chromatic and Reini Urban, who are on opposite sides of the fence on this particular issue, and who are apparently also not the best of friends.

    You're making another big assumption. Please stop.

[reply]
      Again, correct me. Telling me to stop will achieve nothing.
[reply]
Re^3: Perl 5 Optimizing Compiler, Part 2
by flexvault (Monsignor) on Aug 22, 2012 at 12:42 UTC

    Hello Will_the_Chill,

    Thanks for removing the email address.

    I don't think I'm confused about how to write a compiler, since I was very much involved in that in the past.

    What you are minimizing is the '...lack of bytecode integrity' on the impact of developing a compiler for Perl. This is a religious decision and not a technical issue. Your attempts will fail because the Perl developers don't want you to succeed. Each new version of Perl will need a unique compiler. So you come out with your Perl compiler 5.20.0 and the next week Perl 5.22.0 is released, and the Perl developers point out that you compiler 5.20.0 doesn't work with 5.22.0. True, because now you have to use the bytecode structure of 5.22.0 for your 'new/updated' compiler, and your always in catch up mode.

    Notice, how many are quick to point out that the early attempts at compilers were always 'out of date'.

    I wish you luck, but I was only half joking about Perl7. Perl's strength is The Programming Language, not that it's an interpretative language. Of course you need source code, and to develop the software product you need the power of running in an interpretor, but then you need a compiler to distribute the product. Perl5 has two of the three, and will alway have two of three.

    Thank you

    "Well done is better than well said." - Benjamin Franklin

[reply]
      flexvault, my current plan doesn't necessarily involve utilizing the Perl bytecode representation as a significant part of the optimization process. I'm hoping this and utilization of Reini's B system will avoid the "always out of date" issue.
[reply]

In Section Seekers of Perl Wisdom