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!' }
}
};
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 }
}
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!".
Well, I'd appreciate if you could elaborate on that. Ternary tables are in Conway's Best Practices, and while I certainly don't blindly follow any book, they have worked very well for many people, including myself. Compared to the if/else cascades of pre-5.10 Perl, they win hands down.
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.
It's the other way round: Perl 5 evolution was slow until maybe three years ago, since then it has picked up speed rapidly. 5.12.0 came out five months after 5.10.1. Since then, there are monthly development releases, and 5.13 is already shaping up nicely.
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#.
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.
> Perl 5 exists as it is for the sake of backwards compatibility.
This is really says it all: a language, just like any software, develops when issues are fixed without breaking existing code. What's so ugly with having a language version declaration on top of a file, or something better? Why I can link any language to C and still I'm not able to use different versions of the very same language at once? Having newcomers wrestle with ancient issues is not progress, IMO.
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.
And Perl 5 will stay the most recently released version of Perl 5 (note the number). Perl 5 and Perl 6 are different languages of the same family. They forked roads but drive in the same direction.
(I'm not going to argue any silly pseudo-intellectual ontological rebuttal of "oh but it's not really a release!" because other people have no trouble building productive things with Rakudo, like they've done for the other two releases of Rakudo Star and the other thirty three releases of Rakudo.)
It may be usable, but my point was: you can't call something "complete" when it doesn't implement its own spec. Imagine telling your boss "Look, I've released this thing three times now! I know it's just now doing 85-90% of what you asked, but still, what is your problem?!".
When the spec itself is as feature rich as Perl 6 is, having an 80% complete implementation still accounts for a very usable, very feature rich language to play with and implement useful programs in.
The Rakudo developers have never said that Rakudo Star was a complete implementation of the Perl 6 spec. They called it a useful, usable, "early adopter" distribution of Perl 6 (http://rakudo.org/node/75).
Anyway I'm a "glass is half full" type of person and I view the 85-90% has a good thing (and I think the "boss", ie. Larry Wall would agree :)
... a silly pseudo-intellectual ontological rebuttal of "oh but it's not really a release!"
Are you suggesting there's a better approach to develop software than incremental delivery and design changes based on feedback from real users? That contradicts the experience of the people developing Perl 6, but I'm sure many of us would entertain contrary-but-concrete evidence.
Looks like my post really touched a nerve given your totally over the top characterization of it.
>Are you suggesting ...
No, I'm suggesting that when someone complains that they still can't use perl 6 after all these years it's dishonest and overly defensive to try and claim that an 80% release that's apparently been released multiple times makes their complaint a complaint of ignorance.
A more honest approach would be to respond "well, that's true but we're working on it and you can help by using what we have so far".
I'm suggesting that when someone complains that they still can't use perl 6 after all these years....
I don't read that in any sense in what you wrote before ("Perl 6 is somewhere on the horizon").
I don't know anyone's specific needs to deploy Perl 6 for Serious Production Code, but I do know that multiple implementations have been available for five and a half years such that anyone interested could evaluate its suitability and that the purpose of the Rakudo Star releases is to produce code usable for more and more people.
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.
From @chromatic_x: "@shadowcat_mst I use the word "apologetics" in its medieval sense of "a rigorous defense" not "an excuse"."
So, ok, then it was apologetics for lack of a feature. Also, my english is apparently insufficient, and I've only discovered this after the edit has timed out.
As the child of two english literature graduates, I am now going to crawl into a corner and turn bright red for a few minutes. Sorry.
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!).
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).
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.