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.
| [reply] |
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.
*) and it might be worth checking if cperl's implementation of signatures broke any official XS API.
| [reply] |
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. | [reply]
[d/l] |
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.
| [reply] |
