develooper Front page | perl.perl5.porters | Postings from March 2015


Thread Previous | Thread Next
Craig A. Berry
March 8, 2015 13:47
Message ID:
On Sat, Mar 7, 2015 at 9:23 AM, Zefram <> wrote:

> Just to be clear, I'm not advocating that new optimisations should
> *only* be available as CPAN modules.  I'm relaxed about migration of
> optimisations between the core and CPAN.  New core optimisations can
> usefully go on CPAN to be applied to older cores,

So the idea is that various CPAN modules and core components will all
rewrite portions of the optree on the fly without interfering with
each other, that these different optimizations may switch from core to
CPAN or vice versa between Perl versions, but somehow the CPAN
implementations can continue to work without modification across Perl
versions?  Even if that can work (and I'm skeptical), it sounds at
best like a complex design with very high maintenance costs. Actually
calling it a design is premature as the unanswered questions are too
fundamental, such as when a CPAN module and the core both try to
perform the same optimization, who wins?

> and CPAN modules can
> also act as testbeds for optimisations to later be adopted into core.

IMO this is really the only viable use case, and the shorter-lived the
experiment the better.  If it works, get it into core where it

This discussion has nominally been about architecture, but it really
ought to include costs.  You can't run a .pyc file in a version of
Python other than the version that compiled it.  Presumably the Python
maintainers reserve the right to change opcodes and/or the binary
format in which they are stored between versions, or put the other
way, they refuse to incur the costs of maintaining such compatibility
between versions.

People are asking Perl to provide a flexibility that Python does not,
but so far no one is offering to pay for the extra flexibility and
complexity.  Last I heard, Python core development had more resources
to draw on than Perl core development, so I really don't see how we're
in a better position to do this than they are. If experience is any
guide, the costs would simply never be paid and there would just be
yet another constraint on core development. Or in other words, if
people are successful in arguing that the optree is part of the public
API and its details must remain compatible across versions, then the
most likely outcome is work like Dave's will simply grind to a halt
and nothing will take its place.

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About