To be fair, so does Perl 5. Perl 5.18.0 happens to be the yearly major release.
To my knowledge, Rakudo hasn't reached the point where its developers call any Star (runtime plus libraries) release a "major release" of the sort that users ought to use in the wild for a year or more.
From the perspective of somebody who needs a production-grade Perl implementation, Rakudo doesn't cut it, I'm saddened to say.
Monthly releases are a good step in the right direction, but they aren't very useful to those of us who need something more robust.
Perl 5 currently offers this robustness, while Rakudo unfortunately does not. The other Perl 6 implementations end up being worse than Rakudo in this respect, as well.
I think there should be some kind of changing of names. For a while it looked like it's another incremental step, if a big one. Which obviously requires running two implementations in parallel for a while -- similar to Python 2 and 3, or several operating systems and distros.
But right now, especially once Perl development really picked up, it might be time to "divorce" the two languages. It seems more like Algol60 vs. Algol68, or Modula-2 vs. Modula-3. Sure, there's a number in there, but it isn't just about the version of the main implementation.
Having said that, kudos to the Perl team. I really like that they now release new versions pretty regularly, which is a good sign to show people that Perl5 ist still very much alive and nobody needs to hold their breath for the time being.
If only I could use something more recent than 5.8 at work...
In the end, everything is syntax. In the first solution, the inner sub would be called as "$inner->()" or "&$inner()". With lexical subs, we get the much nicer syntax "inner()". This decreases the syntactic pain when structuring your code to use nested functions, thus encouraging good design.
Oh, and I guess lexical subs can have prototypes, which were ignored when calling a coderef with `&` or `->()`. This allows to create really nice, but properly scoped pseudosyntax.
"This allows to create really nice, but properly scoped pseudosyntax."
OK, I can think of some chunks of code I've written where that would make modest sense.
While my benefit/cost threshold for adding a syntax feature is generally much higher than the Perl team's (... much, much higher...), this does seem to fit in with their other additions then. Thanks.
The dynamic scoping in Perl seems a bit troublesome to me. Maybe even a security issue. Can you prevent functions you call from accessing variables in your scope? Do you have to somehow sanitize your scope if this is an issue? Seems a little bit worrying. With the exception of closures inside nested functions, I wish functions just had their own scope and if you want them to have anything else, just pass it in.
This is why wise Perl programmers turn on use strict, and then declare variables with my. Now attempting to dynamically scope stuff is a compilation error. (Except for some built in variables, like $_. Which you don't use in real programs.)
This has been standard advice since the last millennium. But you can't change it without breaking backwards compatibility.
That said, I do have several good uses for local. But not normal ones. My favorite is to use local to dynamically scope entries in a hash. I wind up using this every year or two to put in an automatic check to catch infinite recursion.
I like local for two big uses: One, in unit testing, it's a cheap way to completely mock out a function within some scope. I know there's various test methods for that, but frankly local'ing a glob is so easy both to use and to make do exactly what I need that it's often still easier than even invoking the library.
Second, I love it for security-related stuff where I really don't want something to escape a scope. I have a value that represents the current user I am processing a request for, which is used for security checks, and by local'ing the variable in the context of the handler, I can be very confident that it absolutely, positively will not escape into the next request.
It also turns out to mean that if you're in a code base that has some unfortunate "global" variables, that local lets you turn them into much less "global" variables, as you can local them with confidence about how it won't escape out of scope. Of course, the better solution is to not do that, or to fix it, but we don't live in a perfect world....
When I first started using perl, I too, worried about this and other similar issues. But after 10+ years of using perl, I've never -- not once -- actually run into this problem in the real world.
Can you prevent functions you call from accessing variables in your scope?
Perl's access control model uses a metaphor of polite permission. Without hardware enforcing memory protection, any memory protection at the language level is a modest barrier for the determined anyhow.
Almost ;-) The current perl version is 5.018000, so that would take 982 releases until the numbering scheme breaks down. Of course, Perl v-strings can have elements of INT_MAX each, but I doubt such high numbers would ever be used, for back-compat reasons.
I understand why smartmatch is labeled experimental, but what's the "modern Perl" replacement for given/when? I only use it as a stupid switch statement but I don't want it breaking with Perl 5.22 either...
Readit News
http://search.cpan.org/~rjbs/perl/pod/perldelta.pod
http://rakudo.org/how-to-get-rakudo/
http://rakudo.org/downloads/rakudo/
To my knowledge, Rakudo hasn't reached the point where its developers call any Star (runtime plus libraries) release a "major release" of the sort that users ought to use in the wild for a year or more.
Monthly releases are a good step in the right direction, but they aren't very useful to those of us who need something more robust.
Perl 5 currently offers this robustness, while Rakudo unfortunately does not. The other Perl 6 implementations end up being worse than Rakudo in this respect, as well.
But right now, especially once Perl development really picked up, it might be time to "divorce" the two languages. It seems more like Algol60 vs. Algol68, or Modula-2 vs. Modula-3. Sure, there's a number in there, but it isn't just about the version of the main implementation.
Having said that, kudos to the Perl team. I really like that they now release new versions pretty regularly, which is a good sign to show people that Perl5 ist still very much alive and nobody needs to hold their breath for the time being.
If only I could use something more recent than 5.8 at work...
Dead Comment
In particular, I'm lost on the difference between
and (I mean this as an honest question. That said, I do hope that I'm missing something and this is more than just a syntax gloss.)[1]: http://search.cpan.org/~rjbs/perl-5.18.0/pod/perlsub.pod#Lex...
Oh, and I guess lexical subs can have prototypes, which were ignored when calling a coderef with `&` or `->()`. This allows to create really nice, but properly scoped pseudosyntax.
OK, I can think of some chunks of code I've written where that would make modest sense.
While my benefit/cost threshold for adding a syntax feature is generally much higher than the Perl team's (... much, much higher...), this does seem to fit in with their other additions then. Thanks.
May break horribly.
"state sub creates a subroutine visible within the lexical scope in which it is declared. The subroutine is shared between calls to the outer sub."
So you should be using "state sub"
Or use python which has non-experimental "inner functions"
This has been standard advice since the last millennium. But you can't change it without breaking backwards compatibility.
That said, I do have several good uses for local. But not normal ones. My favorite is to use local to dynamically scope entries in a hash. I wind up using this every year or two to put in an automatic check to catch infinite recursion.
Second, I love it for security-related stuff where I really don't want something to escape a scope. I have a value that represents the current user I am processing a request for, which is used for security checks, and by local'ing the variable in the context of the handler, I can be very confident that it absolutely, positively will not escape into the next request.
It also turns out to mean that if you're in a code base that has some unfortunate "global" variables, that local lets you turn them into much less "global" variables, as you can local them with confidence about how it won't escape out of scope. Of course, the better solution is to not do that, or to fix it, but we don't live in a perfect world....
Oh really? What's wrong with $_ and since when it is?
Perl's access control model uses a metaphor of polite permission. Without hardware enforcing memory protection, any memory protection at the language level is a modest barrier for the determined anyhow.