7 ms·

What’s new in Perl 5, Version 13

59 points by draegtun 16y ago

prakashk 16y ago
I like the changes. Best of all, the non-destructive substitution.
- draegtun 16y ago
  Here is a list of changes since 5.12 (thus far!): * http://search.cpan.org/~shay/perl-5.13.5/pod/perl5131delta.pod http://search.cpan.org/~shay/perl-5.13.5/pod/perl5131delta.p... * http://search.cpan.org/~shay/perl-5.13.5/pod/perl5132delta.pod http://search.cpan.org/~shay/perl-5.13.5/pod/perl5132delta.p... * http://search.cpan.org/~shay/perl-5.13.5/pod/perl5133delta.pod http://search.cpan.org/~shay/perl-5.13.5/pod/perl5133delta.p... * http://search.cpan.org/~shay/perl-5.13.5/pod/perl5134delta.pod http://search.cpan.org/~shay/perl-5.13.5/pod/perl5134delta.p... * http://search.cpan.org/~shay/perl-5.13.5/pod/perldelta.pod http://search.cpan.org/~shay/perl-5.13.5/pod/perldelta.pod
- onedognight 16y ago
  I agree that s///r is quite nice. In particular a use case that was not mentioned is that chained substitutions are now allowed. $foo = $bar =~ s/this/that/r =~ s/that/the other/r;
wazoox 16y ago
These are great enhancements! Particularly, no $@ clobber, non destructive substitution, the news octal escape, the faster shift. These I'm more doubtful : New given/when return, why is that? new package block, why not... don't know if it's really worth it. Anyway kudos for all the great work.
- sigzero 16y ago
  The given/when replaces the kludge that is SWITCH I think. I like the new package block. I am not exactly sure why though. Thanks for the link.
  - draegtun 16y ago
    Yes given/when was added at perl 5.10 (2007) as the Perl6 style "alternative" to the Switch source filter kludge. Switch usage was deprecated and will now be removed from core with perl 5.13/5.14.
- draegtun 16y ago
  New given/when return, why is that? Allows DRYer code. So something like this: say do { if ($grade eq 'A') { 'Well done!' } elsif ($grade eq 'B') { 'Try harder!' } elsif ($grade eq 'C') { 'You need help!!!' } else { 'You are just making it up!' } }; Could now be written this way: say do { given ($grade) { 'Well done!' when 'A'; 'Try harder!' when 'B'; 'You need help!!!' when 'C'; default { 'You are just making it up!' } } };
  - thomas11 16y ago
    But then, you could always use ternary tables: say do { ($grade eq 'A') ? 'Well done!' : ($grade eq 'B') ? 'Try harder!' : ($grade eq 'C') ? 'You need help!!!' : 'You are just making it up!'}; I guess `given` with smart-match looks better when the implicit `~~` test is more complicated than `eq`.
    - draegtun 16y ago
      Yep but the given/when is DRYer because you don't need to repeat the $grade eq re: smart match & more complicated than `eq` - Yes you can push given/when quite a bit: given (TheTime->of_day) { when ('morning') { breakfast(); make_packed_lunch() if $_->is_work_day; } lunch() when 'afternoon'; when ('evening') { goto_pub() if $_->is_friday; dinner(); } default { say "Should be sleeping if its " . $_->{dt}->ymd } } ref: http://stackoverflow.com/questions/3638892/what-kind-of-neat-use-cases-exist-for-given-when/3696479#3696479 http://stackoverflow.com/questions/3638892/what-kind-of-neat...
    - wazoox 16y ago
      There are so many ways to shoot yourself in the foot with imbricated ternary tables that I don't even understand why you use them as an argument. It screams "don't do this!".
      - 16y ago
berntb 16y ago
Why is there no work on a synonym to sub { } with parameter declarations, preferably like Perl 6? I guess the answer will be: "At least join the 20th century, MooseX::Declare is old. Almost 2 years!"? :-) Another thing: Changing precedence for parameter parsing (functions with prototypes) -- won't that kneecap a lot of old code?!
- phaylon 16y ago
  MooseX-Declare is a bit more than that. If you simply want signatures, take a look at Function::Parameters (for functions) or Method::Signatures::Simple (for methods with an invocant).
  - draegtun 16y ago
    And also (and definitely not last!) there is Method::Signatures (http://search.cpan.org/dist/Method-Signatures/ http://search.cpan.org/dist/Method-Signatures/) which adds both function & method signatures.
- draegtun 16y ago
  Changing precedence for parameter parsing (functions with prototypes) -- won't that kneecap a lot of old code?! Hopefully not. Its a bug fix so anyone using unary functions with protoypes may have noticed that it didn't always work correctly before (touch wood!). * http://search.cpan.org/~shay/perl-5.13.5/pod/perl5134delta.pod#Change_in_the_parsing_of_certain_prototypes http://search.cpan.org/~shay/perl-5.13.5/pod/perl5134delta.p... * http://groups.google.com.cy/group/perl.perl5.porters/browse_thread/thread/398f075aef290e06/2af61879a326f935 http://groups.google.com.cy/group/perl.perl5.porters/browse_...
- mst 16y ago
  Because 'use signatures','use Function::Signatures','use Method::Signature::Simple' and 'use MooseX::Method::Signatures' all exist, and work well, but the CPAN cage match still continues for the One True Way. And since that effectively means that adding it into core would merely be an optimisation, it's preferred to wait until a standard has been settled upon so we don't end up having to maintain compatibility with something people have since discovered is a bad idea. The keyword parsing hooks added for version 12 make adding new keywords to experiment even easier, as well - so I think you can expect some signature form to go into core by v16 at the latest (2012), with the advantage that because the current solutions are CPAN modules your code using signatures of one of those sorts today won't break if/when that happens. edit: and as for chromatic's tweet, this is not "apologetics for lack of a feature", this is a personal explanation of why I haven't attempted to write a patch for this yet, but will be seriously considering doing so at some point unless somebody else gets there first. And as schwern points out, there's movement towards a unified syntax for invoking such things that we can quite possibly repurpose later.
InclinedPlane 16y ago
It's sad that the rate of Perl evolution has slowed to the rate of Java evolution, if not slower.
- chromatic 16y ago
  Why do you say that? Java's still not up to the features of Perl 5 (released in 1994). Besides, if you want evolution in Perl, look to the CPAN or Perl 6.
  - InclinedPlane 16y ago
    I'm talking about rate of change in the core language. Nobody sane would look at Perl 5 and say "ayup, this is an excellent stopping point, this language is a perfect distillation of the core Perl ideals and idioms". And yet despite fewer hindrances than Java, Perl has stagnated just as much. (If you want to talk modules and unreleased languages you might as well bring in Clojure, Scala, Jython, etc.) If you really want to be embarrassed by Perl's stagnation, compare it to Python, Ruby, or even C#.
    - chromatic 16y ago
      What an artificial distinction to make! Perl 5 exists as it is for the sake of backwards compatibility. Very few misfeatures suffer deprecation, few deprecations experience removal, and almost any code example you can find as far back as 1987 runs unmodified on Perl 5.13.x (whichever monthly release is the most recent). I also find it difficult to compare language features between Python and Ruby or Perl when neither Python nor Ruby can get lexical scoping right. That seems like a very basic principle of language design. Update: I forgot to write that Perl 6 is the Perl version which explores improvements in the core language.
      - InclinedPlane 16y ago
        My point is that Perl 5 is still the most recent released version of Perl. Perl 6 is somewhere on the horizon (out there with Java 1.6 and C++ 0x). Even if Perl 6 gets released tomorrow, then what? Another decade and a half until Perl 7? Nobody's going to wait around another 30 or 45 years for Perl to become the language it was meant to be, they'll move on long before then, if they haven't already.

59 points by draegtun 16y ago

prakashk 16y ago

I like the changes. Best of all, the non-destructive substitution.

draegtun 16y ago
Here is a list of changes since 5.12 (thus far!): * http://search.cpan.org/~shay/perl-5.13.5/pod/perl5131delta.pod http://search.cpan.org/~shay/perl-5.13.5/pod/perl5131delta.p... * http://search.cpan.org/~shay/perl-5.13.5/pod/perl5132delta.pod http://search.cpan.org/~shay/perl-5.13.5/pod/perl5132delta.p... * http://search.cpan.org/~shay/perl-5.13.5/pod/perl5133delta.pod http://search.cpan.org/~shay/perl-5.13.5/pod/perl5133delta.p... * http://search.cpan.org/~shay/perl-5.13.5/pod/perl5134delta.pod http://search.cpan.org/~shay/perl-5.13.5/pod/perl5134delta.p... * http://search.cpan.org/~shay/perl-5.13.5/pod/perldelta.pod http://search.cpan.org/~shay/perl-5.13.5/pod/perldelta.pod
onedognight 16y ago
I agree that s///r is quite nice. In particular a use case that was not mentioned is that chained substitutions are now allowed. $foo = $bar =~ s/this/that/r =~ s/that/the other/r;

wazoox 16y ago

These are great enhancements! Particularly, no $@ clobber, non destructive substitution, the news octal escape, the faster shift. These I'm more doubtful : New given/when return, why is that? new package block, why not... don't know if it's really worth it. Anyway kudos for all the great work.

sigzero 16y ago
The given/when replaces the kludge that is SWITCH I think. I like the new package block. I am not exactly sure why though. Thanks for the link.
- draegtun 16y ago
  Yes given/when was added at perl 5.10 (2007) as the Perl6 style "alternative" to the Switch source filter kludge. Switch usage was deprecated and will now be removed from core with perl 5.13/5.14.
draegtun 16y ago
New given/when return, why is that? Allows DRYer code. So something like this: say do { if ($grade eq 'A') { 'Well done!' } elsif ($grade eq 'B') { 'Try harder!' } elsif ($grade eq 'C') { 'You need help!!!' } else { 'You are just making it up!' } }; Could now be written this way: say do { given ($grade) { 'Well done!' when 'A'; 'Try harder!' when 'B'; 'You need help!!!' when 'C'; default { 'You are just making it up!' } } };
- thomas11 16y ago
  But then, you could always use ternary tables: say do { ($grade eq 'A') ? 'Well done!' : ($grade eq 'B') ? 'Try harder!' : ($grade eq 'C') ? 'You need help!!!' : 'You are just making it up!'}; I guess `given` with smart-match looks better when the implicit `~~` test is more complicated than `eq`.
  - draegtun 16y ago
    Yep but the given/when is DRYer because you don't need to repeat the $grade eq re: smart match & more complicated than `eq` - Yes you can push given/when quite a bit: given (TheTime->of_day) { when ('morning') { breakfast(); make_packed_lunch() if $_->is_work_day; } lunch() when 'afternoon'; when ('evening') { goto_pub() if $_->is_friday; dinner(); } default { say "Should be sleeping if its " . $_->{dt}->ymd } } ref: http://stackoverflow.com/questions/3638892/what-kind-of-neat-use-cases-exist-for-given-when/3696479#3696479 http://stackoverflow.com/questions/3638892/what-kind-of-neat...
  - wazoox 16y ago
    There are so many ways to shoot yourself in the foot with imbricated ternary tables that I don't even understand why you use them as an argument. It screams "don't do this!".
    - 16y ago

berntb 16y ago

Why is there no work on a synonym to sub { } with parameter declarations, preferably like Perl 6? I guess the answer will be: "At least join the 20th century, MooseX::Declare is old. Almost 2 years!"? :-) Another thing: Changing precedence for parameter parsing (functions with prototypes) -- won't that kneecap a lot of old code?!

phaylon 16y ago
MooseX-Declare is a bit more than that. If you simply want signatures, take a look at Function::Parameters (for functions) or Method::Signatures::Simple (for methods with an invocant).
- draegtun 16y ago
  And also (and definitely not last!) there is Method::Signatures (http://search.cpan.org/dist/Method-Signatures/ http://search.cpan.org/dist/Method-Signatures/) which adds both function & method signatures.
draegtun 16y ago
Changing precedence for parameter parsing (functions with prototypes) -- won't that kneecap a lot of old code?! Hopefully not. Its a bug fix so anyone using unary functions with protoypes may have noticed that it didn't always work correctly before (touch wood!). * http://search.cpan.org/~shay/perl-5.13.5/pod/perl5134delta.pod#Change_in_the_parsing_of_certain_prototypes http://search.cpan.org/~shay/perl-5.13.5/pod/perl5134delta.p... * http://groups.google.com.cy/group/perl.perl5.porters/browse_thread/thread/398f075aef290e06/2af61879a326f935 http://groups.google.com.cy/group/perl.perl5.porters/browse_...
mst 16y ago
Because 'use signatures','use Function::Signatures','use Method::Signature::Simple' and 'use MooseX::Method::Signatures' all exist, and work well, but the CPAN cage match still continues for the One True Way. And since that effectively means that adding it into core would merely be an optimisation, it's preferred to wait until a standard has been settled upon so we don't end up having to maintain compatibility with something people have since discovered is a bad idea. The keyword parsing hooks added for version 12 make adding new keywords to experiment even easier, as well - so I think you can expect some signature form to go into core by v16 at the latest (2012), with the advantage that because the current solutions are CPAN modules your code using signatures of one of those sorts today won't break if/when that happens. edit: and as for chromatic's tweet, this is not "apologetics for lack of a feature", this is a personal explanation of why I haven't attempted to write a patch for this yet, but will be seriously considering doing so at some point unless somebody else gets there first. And as schwern points out, there's movement towards a unified syntax for invoking such things that we can quite possibly repurpose later.

InclinedPlane 16y ago

It's sad that the rate of Perl evolution has slowed to the rate of Java evolution, if not slower.

chromatic 16y ago
Why do you say that? Java's still not up to the features of Perl 5 (released in 1994). Besides, if you want evolution in Perl, look to the CPAN or Perl 6.
- InclinedPlane 16y ago
  I'm talking about rate of change in the core language. Nobody sane would look at Perl 5 and say "ayup, this is an excellent stopping point, this language is a perfect distillation of the core Perl ideals and idioms". And yet despite fewer hindrances than Java, Perl has stagnated just as much. (If you want to talk modules and unreleased languages you might as well bring in Clojure, Scala, Jython, etc.) If you really want to be embarrassed by Perl's stagnation, compare it to Python, Ruby, or even C#.
  - chromatic 16y ago
    What an artificial distinction to make! Perl 5 exists as it is for the sake of backwards compatibility. Very few misfeatures suffer deprecation, few deprecations experience removal, and almost any code example you can find as far back as 1987 runs unmodified on Perl 5.13.x (whichever monthly release is the most recent). I also find it difficult to compare language features between Python and Ruby or Perl when neither Python nor Ruby can get lexical scoping right. That seems like a very basic principle of language design. Update: I forgot to write that Perl 6 is the Perl version which explores improvements in the core language.
    - InclinedPlane 16y ago
      My point is that Perl 5 is still the most recent released version of Perl. Perl 6 is somewhere on the horizon (out there with Java 1.6 and C++ 0x). Even if Perl 6 gets released tomorrow, then what? Another decade and a half until Perl 7? Nobody's going to wait around another 30 or 45 years for Perl to become the language it was meant to be, they'll move on long before then, if they haven't already.