Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot
 
PerlMonks  

Re^9: Pre vs Post Incrementing variables

by BrowserUk (Pope)
on Sep 13, 2010 at 09:19 UTC ( #859957=note: print w/ replies, xml ) Need Help??


in reply to Re^8: Pre vs Post Incrementing variables
in thread 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)

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)

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

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

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.


Comment on Re^9: Pre vs Post Incrementing variables
Select or Download Code
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.
      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.
Re^10: Pre vs Post Incrementing variables
by shmem (Canon) 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'

    should yield 7 instead of 2. Ah, well... ;-)

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://859957]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others examining the Monastery: (4)
As of 2014-08-30 05:20 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (291 votes), past polls