How dare you ... :´(

So you want to freeze P5's core as it is and delegate all extensions to CPAN?

But don't you think that features like sub signatures with ...

• named arguments,
• default values and
• parameter checking

And what's "Peter Martin's work" ?

°) /me crushing eggs in anger (in-joke ;-)

Named arguments, default values, parameter checking are all syntactic sugar, which sure, is somewhat nice to have, but is no possible way essential. Every time you go "I can do this using this little longer syntax" - you already disqualified it as a "long overdue must have feature".

If anything they are not long overdue: they are too late to the party. Using such snazziness would require me to leave behind 5.8-style perl, at which point I might as well leave perl behind altogether. The more "modern" you get, the geometrically smaller the pool of folks who would benefit from your work.

This is something I had to write 2 months ago. I can not write this in perl, and am not likely to ever be able to. Before you go "but async" - I will point out that in the entirety of my career IO has never been an issue. Given certain level of competence, you almost invariably end up bottlenecked on CPU.

But sure, let's talk about signatures and postfix-deref 🤮

> Named arguments, default values, parameter checking are all syntactic sugar, which sure, is somewhat nice to have, but is no possible way essential.

I remember a talk from Damian from YAPC 2011 or 2012 showing the benefits of porting to Perl 6.

The thing that stuck the most was when he showed how his subs shrank 30-50% only by using function signatures with parameter checking.

> Every time you go "I can do this using this little longer syntax" - you already disqualified it as a "long overdue must have feature".

Sorry it's not a little longer syntax, and training new programmers in how best to unpack @_ is a PITA.

But, what's your concern here?

That the syntax won't work on older Perl-versions???

FWIW: It's possible to implement it with syntactic sugar in pure Perl without any XS, but the syntax would require at least one new sub args() which is called to unpack @_

 
sub foo {
    args 
        my $x, 
        my $y ="default", 
        name => my $name ="def2";

    ... #body

}
[download]

When using Keyword::Simple this would also come without speed penalty, because args would be evaluated at compile time.

Is that acceptable for you???

> This is something I had to write 2 months ago.

I'm no Go-go-boy , no idea what that means.

> But sure, let's talk about signatures and postfix-deref 🤮

I'm not fond about postfix-deref tho I'd avoid this emoji when criticizing other peoples work.

But I'm a big fan of autobox which is backwards compatible.

Something like $HoA{key}->push(1,2,3); is more readable than push @{$HoA{key}},1,2,3; , not only to beginners.

Problem is that Autobox comes with a speed penalty, because ->push triggers a method lookup in a wrapper class for arrays (or undef scalars)

A fast implementation would need to create Op-Codes for certain "special" methods like ->push or '->shift'.

If the LHS is an array it would just execute the code for push() and 'shift()', etc without performance lost.

Otherwise they would fall back to normal method lookup for objects.

That's the way I would go for newer features:

• first implementing a slow but light-weight backwards compatible variant
• than implementing a fast XS variant on the same syntax and semantics
• after a phase of proven experimental feature integrating it into the core language.
Does this fit into your requirements, or do you still think Perl core should be frozen?

PS: I'm using // nearly every day...

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery}

Named arguments, default values, parameter checking are all syntactic sugar, which sure, is somewhat nice to have, but is no possible way essential. Every time you go "I can do this using this little longer syntax" - you already disqualified it as a "long overdue must have feature".

Really, anything beyond binary can be considered syntactic sugar. It's up to you to decide how much you want, but I don't believe refusing a feature because it is "syntactic sugar" is reasonable; there are other, better criteria for this.

This is something I had to write 2 months ago. I can not write this in perl, and am not likely to ever be able to.

Ah, but this doesn't necessarily mean it can't be written in perl. You might just need to use a little longer syntax. ;)