Perl 5 is alive and well.
While I was happy with Perl 5.10, the gradual but useful improvements since then have been of great help to me and my work. (I'm perhaps most thankful for the thankless work that's gone into Unicode 6.2 compliance and core support for Unicode throughout.) The yearly release cycle has made Perl 5 even more reliable, and that seems likely to continue.
A couple of years ago, someone asked me for my top five list of improvements Perl 5 needed. I was right about a couple, wrong about a couple of others, and missed one or two important ones. For those playing along at home, I missed:
- A yearly release cycle
- The feature pragma
For all its faults, feature broke the logjam by which it was impossible to add new syntax or backwards-incompatible features to Perl 5. The mechanism isn't perfect (especially its implementation), but it allows progress, and for that I'm thankful.
I can't predict what will be ready for Perl 5.18 next April or May, but I can update my list to include features I'd like to see in an upcoming release. I'll go into more detail of each of these features in future installments.
- A metaobject protocol in the core, to improve Perl 5's object system in a well-defined way
- A ctypes-like replacement for simple XS
- A formalized AST between the parser and the code generator, with the ability to manipulate the AST and inject new subtrees in pure Perl 5
- Compact, native-type data structures
- Declarative replacements for procedural code
(For the CL fans in the audience, I like syntax, and I have a lot of trouble giving up CPAN's breadth and cross-platform goodness.)
What's on your list?
The p5-MOP is definitely top of my list. But I would also like to see...
* Subroutine signatures - There's been some talk of this on p5p again recently. Also happy with pulling into the core one (of the many!) CPAN solutions or even a new func or fun keyword.
* Shorter alias for anon subroutines. Something like ^{ say $_[0] } or if possible ^($x){ say $x } would be very nice!
NB. The last time this was discussed on p5p I think it was mentioned that :{ ... } alias was (probably) possible. I do like ^{ ... } and have seen it used for anon functions in another language (Groovy?).
* And while above (IMHO) helps improve code like this $x->cb(sub{ say $_[0] }) to $x->cb(^{ say $_[0] }) wouldn't it be even nicer like $x->cb{ say $_[0] }
For above see patch by Gfx - RFC: A new syntax to give a method an extra block
/I3az/
A core MOP, definitely. I'd also like to see a way to get rid of that extra semicolon at the end of "block functions", ie Try::Tiny.
Like many other people, I think that MOP in the core is a great idea.
Compact data might be nice, but PDL does well enough for numbers, at least for me.
AST though, mmmmm, delicious!
However using the carat to mean sub is just another one of those things we are trying to get rid of in Perl. People see it as spaghetti code already, should we really add ^{} as a thing?! JS uses function(){} for anonymous funcs, this is no different than sub{}.
When passing in anon subs I find sub {} and JS function(){} are often a tad too heavy and can get hard to visually parse with method name.
For eg.
$x->map(sub{ $_ * 3 })->grep(sub{ $_ % 2 == 0 }); $x->map(^{ $_ * 3 })->grep(^{ $_ % 2 == 0 }); $x->map{ $_ * 3 }->grep{ $_ % 2 == 0 };I find the last two much less busy and IMHO more pleasing on the eye.
ill go out on a limb and ask for regex matching syntax to be improved.
my ($foo) = $line =~ m/(A-Z)+/;
yucky.
Named aliases for $_ in map, grep, and anywhere the & prototype is used:
my @list = map my $x { "updated_$x" } @stuff;
my $result = try { ... } catch my $e { warn $e->message };
See Block::NamedVar for a prototype with Devel::Declare.
Structured core exceptions
A way to distinguish between character string and binary string (http://perlalchemy.blogspot.com/2011/08/isutf8-is-useless-can-we-have.html_
I've wanted that for so long I forgot to mention it. Thanks for the reminder!
foo($_) if <condition> for <list>
would shorten 1-liners
Exception handling as core concept as opposed to bolted on eval. try/catch/finally semantics that are not hacked on top of eval. That's not intended as a dig at Try::Tiny and friends which I am ever grateful for daily.