Re^2: "when" and replacements

Replies are listed 'Best First'.
Re^3: "when" and replacements by LanX (Saint) on May 07, 2011 at 09:27 UTC
There is no point in a redundant implementation of the aliasing-behavior of `for ( onearg )`. And aliasing is too powerful for many users, it can cause hard to debug errors thru side-effects. So if you want it use `for`, if you don't want it chose `given`. Cheers Rolf	[reply] [d/l] [select]
Re^3: "when" and replacements by JavaFan (Canon) on May 07, 2011 at 10:55 UTC
There's currently a thread on p5p where some people argue that the non-aliasing behaviour of given is a bug. I kind of like the idea that since one can use when clauses in a `for`, `given` doesn't alias. If you want aliases, write `for`; otherwise, write `given`. OTOH, I don't think I've ever written code where I wanted `given` to alias, nor that I wanted it to not-alias. That is, each time I use `given`, whether `$_` aliases or not, it does not matter.	[reply] [d/l] [select]
Re^4: "when" and replacements by LanX (Saint) on May 07, 2011 at 11:25 UTC
>I kind of like the idea that since one can use when clauses in a for, given doesn't alias. If you want aliases, write for; otherwise, write given. Yeah sounds like perfect orthogonal design. Though one has to keep in mind that leaving the block demands different statements. `use feature qw(switch); given (1) { print; break; print } for (1) { print; last; print }` [download] Cheers Rolf UPDATE: confusingly this works well: `$\="\n"; for ("012") { if (/0/) {print "0 matched"}; # prints 0 when (/1/) {print "1 matched"}; # prints 1 when (/2/) {print "2 matched"}; # nix if (/3/) {print "3 matched"}; # nada }` [download] but the perlsyn says Every "when" block is implicitly ended with a "break". Consequently "break" should also leave loop-blocks, or the documentation should be updated. IMHO `break` is needless and should be abandoned in favor of `last`. (which linguistically still makes sense)	[reply] [d/l] [select]
Re^5: "when" and replacements by JavaFan (Canon) on May 07, 2011 at 12:01 UTC
IMHO break is needless and should be abandoned in favor of last. (which linguistically still makes sense) But `break` doesn't act as `last`. It acts as `next`. But using `next` in a `given/when` to end the `given` would be odd - I'd expect `next` to act as `continue` does now.	[reply] [d/l] [select]
Re^6: "when" and replacements by LanX (Saint) on May 07, 2011 at 12:11 UTC
Re^7: "when" and replacements by JavaFan (Canon) on May 07, 2011 at 13:57 UTC
Some notes below your chosen depth have not been shown here
Re^4: "when" and replacements by John M. Dlugosz (Monsignor) on May 08, 2011 at 01:40 UTC
"least surprise" is a powerful consideration. In Perl 6, you can declare the iteration variable of the `for` to have the desired attributes. For a `given` you could use an expression to cause a copy to be made: `given (0+$x) {...` and if you write a function that just returns its argument, and you call that function `copy`, then you could write `given (copy $x) ...` nice and sugary. It would be harder to impose aliasing if the normal case didn't. But since it's been this way for a while now, I think any "fix" will be to use a pragma to choose the behavior.	[reply] [d/l] [select]
Re^5: "when" and replacements by JavaFan (Canon) on May 08, 2011 at 11:09 UTC
"least surprise" is a powerful consideration. Then, IMO, it should not do aliasing. Aliasing (in for/foreach/map/grep/values) still surprises people, and it causes bugs. Except for the few 1000s of people who are really, really into Perl, most programmers don't know about aliases, and it will catch them off-guard. As for given, it will take a long time before given is used by "the masses" (that is, the 995,000 Perl programmers that aren't deeply connected to it). Most of them will never make the connection that given shares features with for. Even if they know about aliasing in for/foreach, I very much doubt they'll be surprised if given doesn't have it.	[reply]
Re^5: "when" and replacements by LanX (Saint) on May 08, 2011 at 12:58 UTC
After some meditation I think this attempt to transplant Perl6 features with exactly the same syntax is the source of problems. Perl6 handles some fundamental stuffs like sigils differently and I'm not sure if its possible within P6 to use "when"-clauses within "foreach"-blocks. IMHO enforcing every detail leads to anti reactions in the perl5 system. I'd rather prefer a semantical correspondence of features than introducing more breaks in symmetry and logical confusion. For example nobody seems to care that c-style "for" is now "loop" in Perl6...same semantic but different syntax. Cheers Rolf	[reply]