Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options
 
PerlMonks  

Re^12: Curious about Perl's strengths in 2018

by dave_the_m (Monsignor)
on Apr 23, 2018 at 13:57 UTC ( #1213431=note: print w/replies, xml ) Need Help??


in reply to Re^11: Curious about Perl's strengths in 2018
in thread Curious about Perl's strengths in 2018

Thanks, but I don't know how these things apply to subroutine signatures. For instance how does the XS interface hinder the implementation of proper signatures?
Well, I was talking in general terms about why perl5 doesn't tend to get new features, in response to your general compliant about the management of perl5.

But specifically for signatures, there are many things that can break in XS. For example, if we introduce new op types to handle signature processing, then XS modules which manipulate the optree, or which assume certain ops at the start of a sub, or which modify op behaviour by changing their pp_addr function pointer, may all break. Or modules which use keyword plugins and make certain assumptions about allowed syntax. Or XS code which directly manipulates @_. Or code which attempts to hook into subroutine entry and exit. Or profilers that think they know all valid op types.

There are many things that can break just that I can think of; when deployed, there will be other things that break that hadn't even occurred to me.

Dave.

  • Comment on Re^12: Curious about Perl's strengths in 2018

Replies are listed 'Best First'.
Re^13: Curious about Perl's strengths in 2018
by LanX (Archbishop) on Apr 23, 2018 at 15:14 UTC
    These examples sound like XS code exploiting undocumented or internal features, without being widely used.

    Manipulating the OP Tree? Does really anyone seriously use B::Generate ?

    I'd be interested to see official API which would break with signatures

    I can't see how 3rd party modules like Function::Parameters break XS code while implementing most of Perl6 semantics.*

    It's a matter of management to introduce an experimental feature and give module maintainers exploiting undocumented stuff a time span to fix their code (or not).

    The benefits of decent signatures outweighs any possible damage.

    And not all modules are as important as JSON::XS and not all maintainers are reluctant to improvement like Schmorp is.

    I hope you see my point.

    Cheers Rolf
    (addicted to the Perl Programming Language and ☆☆☆☆ :)
    Wikisyntax for the Monastery

    *) and it might be worth checking if cperl's implementation of signatures broke any official XS API.

      These examples sound like XS code exploiting undocumented or internal features, without being widely used.
      I think that this really demonstrates that you have a rather idealistic view of perl core development. In reality, lots of things we change break CPAN modules, and people shout at us. And even if the module was being naughty, we're often told in no uncertain terms that because that module is a dependency for lots of other CPAN distributions we need to fix the module or roll back the perl change.

      For example, if you install Moose, you pull in the following XS dependencies, some of which quite blatantly violate the XS API, or skirt its edges:

      Package::Stash::XS Params::Util Class::Load::XS Sub::Identify Sub::Name Variable::Magic Devel::Caller Devel::LexAlias PadWalker
      and it might be worth checking if cperl's implementation of signatures broke any official XS API
      cperl's implementation is based on perl's implementation, plus my OP_SIGNATURE optimisation work, which I felt wasn't yet in a good enough state to merge into blead, but Reini decided it was ok for cperl. Other than that, the main differences are that cperl eliminates @_, and conflates signatures and prototypes.

      Did it break the XS API? That depends on your point of view. For example, It added a new op (as did the perl implementation), and part of the XS API allows you to hook into the peephole optimiser. If an XS module which does additional peephole optimisation crashes because it doesn't recognise the new OP type, is that our fault or theirs? But people don't care whose fault it is if you can no longer install Moose, say - they just want sometime to fix the problem.

      Dave.

        Many of these XS modules build on PadWalker or offer a pure Perl fall back or reflect inspection which should be supported by a stable API.

        But I don't wanna discuss Moose, there are good reasons why I prefer Moo. (Ironically I never published my Macro module on cpan because I couldn't get rid of PadWalker dependency)

        You and Reini are obsessed of speed, that's why you try to eliminate @_.

        But Ruby convinced people as a "cleaner Perl" while being half as fast.

        Mind you that computers became 1000 times faster in 15 years* and try to calculate the positive effect of "slow" signatures introduced in the early 2000s.

        Did anyone yell at you because the experimental signature implementation breaks anything? It's just syntactic sugar injecting pure Perl code in the body. (Well except of me? ;-) I told my clients not to use it, because if the API for named args is missing, the risk of another "smart-match" disaster is too big.

        We are becoming a community of grandpa's who want no change and are driving away fresh blood which can't find confidence in a language which not only lacks signatures, but can't evolve anymore and seems to be locked in a dead end of evolution.

        Cheers Rolf
        (addicted to the Perl Programming Language and ☆☆☆☆ :)
        Wikisyntax for the Monastery

        *) More's law

      These examples sound like XS code exploiting undocumented or internal features, without being widely used.

      For a long time, there was no strong line between "documented" and "internal only features" in XS. Furthermore, there's still a persistent belief that CPAN modules should support dozens of releases of multiple stable major versions of Perl going back multiple years.

      XS-as-extension language being the same as XS-as-implementation-language is a big blocker to major internal rewrites. If a solution to that had begun in 2000/2001 (instead of wasting a decade and a half producing Advanced Perl Substitute), we might be seeing the benefits of it now.

        I doubt that those who were energized and mobilized by the greenfield of Perl6 would have had the intestinal fortitude to attack the problems cited in this thread; which were largely socially bounded anyway.

        Well lack of management, vision and strategy replaced with pseudo religious hubris.

        Ironically does the Mythical Man Month already predict how a "second system" becomes overloaded and impossible to implement.

        Well the first good argument for Perl 6 I heard was that maintenance will become much easier. It was a certain chromatic who convinced me...;)

        Anyway in absence of a time machine we should concentrate on what is left and get rid of the weird 10% legacy which hinder the evolution of the remaining 90% of Perl 5.

        Cheers Rolf
        (addicted to the Perl Programming Language and ☆☆☆☆ :)
        Wikisyntax for the Monastery

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1213431]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (4)
As of 2019-07-20 09:50 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?