|
in reply to Re^7: Pre vs Post Incrementing variables
in thread Pre vs Post Incrementing variables
the operands of the comma operator should be the results of the preincrement subexpressions.
Correct. And it does. For good or bad, the result of preincrement is the variable that was incremented. We've covered that you wish it wasn't. I don't disagree.
Not two references to $n after both sub-expressions have been evaluated.
Correct. It doesn't. It returns $n after the first preincrement has been evaluated and $n after the second preincrement has been evaluated. Like I said earlier, the evaluation order is already what you would expect it to be.
use 5.010; # say
use Data::Alias;
sub f { say @_; }
$n=3;
f(++$n, 0+$n, ++$n);
$n=3;
do {
local @_;
alias $_[0] = ++$n;
alias $_[1] = 0+$n;
alias $_[2] = ++$n;
&f;
};
545
545
As for your ploy of resorting to meta-argument to distract from the argument
"You think that you know better what the authors of that passage meant when they wrote it, than they did." is not an argument.
Update: Improved example. |
Re^9: Pre vs Post Incrementing variables
by BrowserUk (Patriarch) on Sep 13, 2010 at 08:51 UTC
|
"You think that you know better what the authors of that passage meant when they wrote it, than they did." is not an argument.
Oh, but it so is.
Having already attempted to point out the significant difference between your "operand evaluation order"--which appears nowhere in either the quoted passage, nor elsewhere in the post; and the phrase "the order of evaluations of expressions"--which does; and having attempted to give you the benefit if the doubt.
I had to conclude, that your conflation of the two terms was not accidental, but rather, knowing and deliberate. At which point, my conclusion was not "slander", but rather 'paraphrase'.
You said it; in the face of my clear attempt at clarification, you repeated it. I paraphrased you. That isn't "slander", it is fact. Slander has to be false.
Slander also has to be spoken. If it's written, it becomes libel, but it still has to be false, but your conflation of two entirely different terms, was palpable; obvious. My conclusion, unavoidable.
And your confusion, deliberate or otherwise, continues. You appear to be trying to make a distinction, between:
two references to $n after both sub-expressions have been evaluated.
And:
Correct. It doesn't. It returns $n after the first preincrement has been evaluated and $n after the second preincrement has been evaluated.
But, $n_after_the_first_increment would be different, by 1, to $n_after_the_second_increment, but your own output--in both the relevant case and your two fantasy cases--shows both digits are the same.
And the only way for that to happen, is for both pre-increments to have occurred, before the subroutine gets whatever it is given. And that is self-evidently wrong, sub-expression evaluation order specified or not.
But...(I can see you clasping your hands together in triumph)... if sub-expression evaluation order was specified, then there is no way possible that the current behaviour could be excused under the "Don't use 2 or more side-effectful operations on a single variable, within a single expression" missive.
In other words, in the hope that it will penetrate this time. If the excuse of "unspecified order of sub-expression evaluation" had never existed, then the current behaviour would have been recognised a bug the moment it was implemented.
And one more try.
If the order of evaluation of sub-expressions was defined--whether left to right, right to left, or in the most obvious order of respecting both precedence and parentheses--then the current implementation of passing lvalue references to the target (operand) of sub-expression operations--rather than the results produced by those sub-expressions--would have stood as an indefensible bug long ago.
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.
| [reply]
[d/l]
[select] |
|
|
But, $n_after_the_first_increment would be different, by 1, to $n_after_the_second_increment, but your own output--in both the relevant case and your two fantasy cases--shows both digits are the same.
It returns $n (the scalar, not the value within) after first increment, not some copy $n_after_the_first_increment after the first increment.
And the only way for that to happen, is for both pre-increments to have occurred, before the subroutine gets whatever it is given.
You are mistaken. The first result in placed on the stack before the second is evaluated. See the code in the grandparent.
| [reply]
[d/l]
[select] |
|
|
You are mistaken.
Nuh uh.
The first result in placed on the stack before the second is evaluated.
When the values are "placed on the stack" IS "before the subroutine gets whatever it is given.". It gets them when it takes them off the stack. And that can't happen until both have been placed on it.
And by the time they have both been placed on the stack, which even you'll have to agree is "before the subroutine get whatever it is given", both increments have occurred.
So, if (references to) the values resulting from the pre-increments were placed on the stack, instead of references to the preincremented variable, then the anomaly would not arise.
And the only thing that allows it have been implemented as is, and to have persisted, is the previously, exhaustively described missive.
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.
| [reply] |
|
|
|
|
| |
|
Correct. It doesn't. It returns $n after the first preincrement has been evaluated and $n after the second preincrement has been evaluated.
But, $n_after_the_first_increment would be different, by 1, to $n_after_the_second_increment, but your own output--in both the relevant case and your two fantasy cases--shows both digits are the same.
Uhm, there's only one variable here, $n. Note that $n is returned, not "the value of $n". Preincrement ++ behaves just like += 1 in this respect.
| [reply]
[d/l]
[select] |
|
|
Having already attempted to point out the significant difference between your "operand evaluation order
The only post between my first use of the term and your slander is Re^3: Pre vs Post Incrementing variables, but it indentifies no differences. Did you forget to post them? If I'm misusing the term, I'll be glad to correct myself.
| [reply] |
|
|
it indentifies no differences. Did you forget to post them?
You somehow failed to notice the very first sentence of that very post? Including the emphasis I applied to the word 'operand'.
And then again failed to notice the strikeout I applied to that same word when I re-quoted your phrase later in that same post?
What more do I have to do to draw attention to the fact that you were discussing something that doesn't appear anywhere in the passage I quoted?
What other conclusion can be drawn from your complete failure to accept the obvious?
And (Damn it) You succeeded in drawing me into a meta-argument. So, I'm done.
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.
| [reply] |
|
|
|
|
