Re^9: Pre vs Post Incrementing variables

By the same logic in f($n) f should be passed the result (value) of $n, disallowing f from modifying $n.

Not so.

If I pass variables to a function, then I expect to get reference to those variables:

$n = 1; 
$m = 2; 
print \$n, \$m;;
SCALAR(0x3d3cf08) SCALAR(0x3e12508)

sub { print \$_[0], \$_[1] }->( $n, $m );;
SCALAR(0x3d3cf08) SCALAR(0x3e12508)
[download]

But, if I pass sub-expressions to a function, I expect to get references to (temporary) variables containing the results of those sub-expressions. And in most cases that's exactly what I get:

sub { print \$_[0], \$_[1] }->( $n+1, $m+1 );;
SCALAR(0x3cc86d0) SCALAR(0x3d3f320)
[download]

I can even mutate those references to results without error:

[0] Perl> sub { print \$_[0], \$_[1]; +$_++ for @_ }->( $n+1, $m+1 );;
SCALAR(0x3cc86d0) SCALAR(0x3d3f320)
2 3
[download]

but, and here is the significant point, those mutations do not modify the variable involved in the sub-expressions from which those results were derived:

print $n, $m;;
1 2
[download]

It is only in the case of pre-increment expressions (and a few other similar anomalies), that the function receives a reference to the target of the sub-expression, rather than a reference to the result of it.

And the clincher that this is a bug, rather than an implementation specific optimisation allowable within the rules of the language definition, is that there is no good use for it.

The justification for many of the anomalies that exist in Perl, is that there are one or more very common cases where the anomalous behaviour is useful, Because it allows the capture, within a concise idiom, a piece of behaviour that is sufficiently commonplace to warrent it. This has no such justification.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

RIP an inspiration; A true Folk's Guy

Comment on Re^9: Pre vs Post Incrementing variables Select or Download Code

Replies are listed 'Best First'.
Re^10: Pre vs Post Incrementing variables by shmem (Chancellor) on Sep 13, 2010 at 14:30 UTC
The justification for many of the anomalies that exist in Perl, is that there are one or more very common cases where the anomalous behaviour is useful, Because it allows the capture, within a concise idiom, a piece of behaviour that is sufficiently commonplace to warrent it. This has no such justification. Well, it might be a common golf case :-D perlop states Terms and List Operators (Leftward) A TERM has the highest precedence in Perl. They include variables, quote and quote-like operators, any expression in parentheses, and any function whose arguments are parenthesized. Actually, there aren’t really functions in this sense, just list operators and unary operators behaving as functions because you put parentheses around the arguments. If that statement was correct, then in the case of `sub { }->(++$c, $c++)` pre- and postincrement would conflate to simple increments of the variable after the sub returned, since -- and ++ have lower precedence than TERM according to the docs, no matter whether pre or post. But for arguments to a sub call, pre-increment seems to mean "increment before sub call" (`$var` done, can be passed as alias), postincrement "increment after sub call" (`$var` must be retained for ++, copy is passed) - which, while intuitive, isn't documented anywhere afaics. But then, one could argue that `perl -E '$c=1; sub{$_[0]+=5}->($c++);say $c'` [download] should yield 7 instead of 2. Ah, well... ;-)	[reply] [d/l] [select]
Re^10: Pre vs Post Incrementing variables by JavaFan (Canon) on Sep 13, 2010 at 09:41 UTC
But, if I pass sub-expressions to a function, I expect to get references to (temporary) variables containing the results of those sub-expressions. Then your expectation is wrong. Perl doesn't guarantee this. And if you want a regular language, Perl isn't for you. It is only in the case of pre-increment expressions (and a few other similar anomalies), that the function receives a reference to the target of the sub-expression, rather than a reference to the result of it. Yeah. It's called lvalues. Just labelling them anomalies doesn't make them bugs. As I said, if you want a regular language, don't use Perl. And the clincher that this is a bug And the ID of your bug report is? This has no such justification. The justification is optimization. (Just as the orginal reason for C). Not in keystrokes, but in execution. Here the optimization is that by returning an alias, it saves creating a new SV. If you don't want the alias, create a copy.	[reply]
Re^11: Pre vs Post Incrementing variables by BrowserUk (Patriarch) on Sep 13, 2010 at 14:16 UTC
If you don't want the alias, create a copy. It not getting an alias that is the problem is it. It's getting the same alias for two or more different sub-expressions. And the ID of your bug report is? There is no point in raising one. Because the problem description would be the OP, and that would be dismissed on the basis of this. Which is underpinned by the passage I quoted here. The justification is optimization. ... it saves creating a new SV. And so we come full circle. We're back to "Perhaps the most short-sighted and pervasive premature optimisation ever." That saving of the creation of a new SV, in the limited cases of pre-increment and assignment operators only--hardly so pervasive in code that it requires optimising--creates the situation that means many useful behaviours are denied the programmer. Along with the resultant contradiction of the principle of least surprise. It's not going to change now, And I didn't set out to make a case for it to change now. Only to document how it came about in the first place. And then support my assertion that the quoted phrase above is indeed the source of the chain of causality. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. RIP an inspiration; A true Folk's Guy	[reply]