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.
Perl 5.18.0 is now available
21–30 of 69 posts
Re: Perl 5.18.0 is now available
#22The 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.
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.
Re: Perl 5.18.0 is now available
#23Earlier quoted context omitted.
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 v…
Perl5 users won't switch to Perl6 because they're working on Perl5 code and don't want to change their habits. Non-Perl devs won't switch to Perl6 because the P word scares them. So, yes, changing the name might be a good idea. And making an enjoyable web-based tutorial.
I am already switching to Perl6.
Re: Perl 5.18.0 is now available
#24Earlier quoted context omitted.
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 v…
Perl5 users won't switch to Perl6 because they're working on Perl5 code and don't want to change their habits. Non-Perl devs won't switch to Perl6 because the P word scares them. So, yes, changing the name might be a good idea. And making an enjoyable web-based tutorial.
Lets assume that I'm switching from Perl5. Why would I switch to Perl6 over something else? Even assuming Perl6 were to be become production ready tomorrow, there is a cornucopia of good languages these days. I'm sure Perl6 can claim to be more expressive than most but is that enough?
Re: Perl 5.18.0 is now available
#25The 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.
Re: Perl 5.18.0 is now available
#26The 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.
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.
I have not been so lucky. I've had to submit patches to CPAN modules because their use of $_ broke dynamically scoped access to $_.
Re: Perl 5.18.0 is now available
#27Can someone explain the point of the lexical subroutines? [1]
In particular, I'm lost on the difference between
sub outer {
my $closurevar;
my $inner = sub {
... use $closurevar...
};
}
sub outer {
my $closurevar;
my sub inner {
... use $closurevar...
}
}
[1]: http://search.cpan.org/~rjbs/perl-5.18.0/pod/perlsub.pod#Lex...
Re: Perl 5.18.0 is now available
#28Can someone explain the point of the lexical subroutines? [1] In particular, I'm lost on the difference between sub outer { my $closurevar; my $inner = sub { ... use $closurevar... }; } and sub outer { my $closurevar; my sub inner { ... use $closurevar... } } (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/~rjb…
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.
Re: Perl 5.18.0 is now available
#29Can someone explain the point of the lexical subroutines? [1] In particular, I'm lost on the difference between sub outer { my $closurevar; my $inner = sub { ... use $closurevar... }; } and sub outer { my $closurevar; my sub inner { ... use $closurevar... } } (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/~rjb…
Aside from the syntactic differences, I would assume that lexical subroutines can have prototypes while subroutines stored in variables cannot.
Re: Perl 5.18.0 is now available
#30Can someone explain the point of the lexical subroutines? [1] In particular, I'm lost on the difference between sub outer { my $closurevar; my $inner = sub { ... use $closurevar... }; } and sub outer { my $closurevar; my sub inner { ... use $closurevar... } } (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/~rjb…
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…
> This decreases the syntactic pain
use 5.018;
no warnings "experimental::lexical_subs";
use feature "lexical_subs";
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"