It does what the docs says. The documentation just glosses over details that turn out to be relevant when magic vars are involved. (Some people think this kind of abstraction is a good thing.)

Certainly I think a good abstract model is a Good Thing. Inter alia it makes the documentation easier both to write and to understand. It should also guide the implementation. We can now discuss what is, or is not, a good abstract model, if you like... but I think we are straying from the point.

One can take the view that what the implementation does is what it should do; and that the documentation is only a rough and ready guide to that.

In this case, an implementation detail that didn't seem relevant, turns out to have a nasty side effect. Unfortunately, that side effect also invalidates other advice in the documentation, and (I believe) common practice. One can take the view that this is what happens when people depend on a description of the language, or (worse yet) some abtract model, instead of the actual implementation. Time to go and fix the documentation, the advice and the common practice... perhaps.

On the other hand, if only for the obvious utility, perhaps local should be more aware of its context (small 'c'), and be changed to not set a variable undef when there is an initializer -- in addition to not changing it before the initializer has been evaluated. If that is what you meant by:

But in this case, we're already in that situation. So maybe it is appropriate here.

However, I cannot resist a debating point when I see one... NB: the following adds nothing to the real issue, so disinterested readers may which to move on to something else now.

They're identical to Perl. Perl doesn't have a concept of initializers. It sees a local, and it sees an assignment. It evaluates both independently.

The implementation may have no concept of initializers, but the language description does. While there is no dissonance it's immaterial -- a distinction that makes no difference. When there is dissonance, however, we seem to disagree on how to resolve the problem.

I understand that local is an operator (a "Named Unary Operator"), which has a higher precedence than '='. It was a small surprise to me, therefore, that:

  our $fred = 78 ;
  local $fred = $fred ? "Still $fred" : 'undef' ;
[download]

  $fred = 78 ;
  $fred = d($fred) + $fred ;

  sub d { $_[0] = 10 ; return 1 ; } ;
[download]

This suggests to me that local is not being evaluated independently of the assignment. Either that, or there is something about the precedence of local and the order of execution which is not the same as the precedence and order of execution of a function call. While the documentation swears blind that Perl functions "can serve as terms in an expression", the behaviour of local with a assignement, is more akin to a declaration.

Of course, I know that it is foolish to assume such simple model, and that I should read the documentation carefully to check what local does in any given circumstance (avoiding the word context, you understand). There I discover that local sets its arguments undef in the absence of an initializer. The documentation is silent on how the old value is saved, when the old value is saved, or whether that process sets the variable undef or not. I see now that I was compounding my original errors, and that I should really consult the code, rather than the documentation !

Second, reaching back up this thread, I said, in the context of local $foo = 78 ; (or similar):

Were it not for the side effect of setting $SIG{ALRM} to undef, nobody would ever be able to tell that being set undef is apparently a step in the initialisation of the local.

Not so. I rely on that feature all the time.

I cannot imagine a useful purpose for the fact that local $foo = 76 ; fleetingly sets $foo to undef, before setting it to the required 76.

There isn't.

Finally, your alternative way of automatically restoring a $SIG entry on scope exit is characteristically clever. Thank you. I will add Sub::ScopeFinalizer to my list of potentially useful stuff.

However, I had suggested that to continue (safely) to use local $SIG{..} = sub ..., in the way described in the documentation, requires the local to be wrapped... To which you replied:

Not so. I already provided code that doesn't use POSIX or local and restores the signal automatically on scope exit.

It was a small surprise to me, therefore, that [local $fred = $fred ? "Still $fred" : 'undef' ;] sets $fred to 'Still 78'

Although it's not documented, all Perl operators except assignment operators evaluate their operands in left-to-right order. Assignment operators evaluate their RHS before their LHS.

sub d :lvalue { print("$_[0]\n"); $_[1] }

d("LHS", 4   ) + d("RHS", 5);  # LHS, RHS
d("LHS", $var) = d("RHS", 1);  # RHS, LHS
[download]

This was specifically done to handle expressions of the form f($var) = g($var). That's why $x = $x + 1 works. That's why my $x = $x; works.

which leaves me wondering where the contradiction is

Sorry, I missed the bold portion in "This second turns out to be essential in order to use local to automatically restore the $SIG state on forced exit (die) from an eval."

It was a small surprise to me, therefore, that local $fred = $fred ? "Still $fred" : 'undef' ; sets $fred to 'Still 78'

Although it's not documented, all Perl operators except assignment operators evaluate their operands in left-to-right order. Assignment operators evaluate their RHS before their LHS.

I'm no fan of code that depends on the order of evaluation of terms -- side effects should be handled carefully, and an expression with multiple, interdependent side effects doesn't look careful to me. (With the exception of '&&' et al, where order is an essential element.) Not forgetting one's primal fear of some hairy-arsed optimiser barging in and laying waste the carefully arranged crockery. So the fact that it's not documented is not an issue, though a formal "not-specified" wouldn't hurt.

That said, left to right evaluation of the terms is not going to surprise. I note that subroutine arguments are also evaluated left to right -- which isn't always the case in other languages.

While I was poking around trying to get a handle on this I thought perhaps the rightward association might be significant. The only other right associative binary I could find is '**'. Experiment shows that this evaluates its arguments left to right too.

The exception for '=' is interesting. Obviously, the LHS of an assignment needs to be evaluated to an lvalue -- the address (in some form) of the destination. Equally obviously, unless one side has a side-effect that affects the other, the order of execution is immaterial. So, making an exception for '=' must have something important in mind. I'm curious what it was. The simple:

  $x = $x + 1 ;
[download]

could happily take the address of $x then evaluate $x + 1 and then assign... surely ? So, what could one reasonably expect:

  $x = 0 ;
  $a[$x++] = $x ;       # $a[0] = 0  or  $a[0] = 1 ??
  $a[$x]   = $x++ ;     # $a[2] = 1  or  $a[1] = 1 ??
[download]

to do ? (Apart from making one queasy.) Is resolving this a good reason for making '=' an exception ? More contrived, but essentially the same:

  sub h { $_[0] = 1 ; return '!' ; } ; 
  $x = 0 ;
  $a[$x] = h($x) ;      # $a[0] = '!'  or  $a[1] = '!' ??
[download]

However simple or complicated one makes this, it comes down to the same thing... is it somehow "obvious" that because we think of the RHS being assigned to the LHS, that the order of execution should favour that ? And, is that worth bending the also "obvious" rule that terms are evaluated left to right ?

Your friend and mine C99 is happy specifying that for an assignment operator, the order of evaluation of its operands is unspecified. Given that Perl doesn't specify the order, and "Good" code would not depend on it anyway -- if only for the sake of clarity -- I guess this is all has, at most, curiosity value.

My (completely unsubstantiated) guess is, however, that the original motivation for making an exception for '=' is our friend local -- which is where we came in. It is "obvious" that:

  $x = $x + 1 ;        # or $x = $x++ ;
[download]

and:

  local $x = $x + 1 ;  # or local $x = $x++ ; (!)
[download]

should yield the same value for $x. But, given that local is just an operator (same like everything else), straightforward left to right evaluation does not do the trick. To fix that one could fiddle with local and/or the parsing thereof. Or fiddle with '=', with the side effect of choosing the less unobvious ordering in other cases. (And, since the order is not defined, who cares ?!) If this were the case, then things have now come full circle :-)

Anyway, putting away this idle speculation (however amusing it might be)... While I was poking at this, I came across the following:

  sub d { $_[0] = 10 ; return 1 ; } ;

  $x = 78 ;
  print "\$x=$x.  \$x + d(\$x) = ", $x + d($x), "  \$x=$x\n" ;
  $x = 78 ;
  print "\$x=$x.  d(\$x) + \$x = ", d($x) + $x, "  \$x=$x\n" ;
[download]

which gives:

  $x=78.  $x + d($x) = 11  $x=10
  $x=78.  d($x) + $x = 11  $x=10

After some headscratching, and having removed the splinters from under my nails, I decided to discount quantum effects... I assume this is an effect of an optimisation which avoids taking a copy of the value of $x. That's fine. The order of execution is not defined, so why should one expect one outcome and not another :-) ?

Using your little trick to observe the order of evaluation:

  sub d { $_[0] = 10 ; return 1 ; } ;
  sub o { print $_[1] ; return $_[0] ; } ;

  $x = 78 ;
  print "\$x=$x.  \$x + d(\$x): " ;
    print o($x, 'LHS ') + o(d($x), 'RHS '), "  \$x=$x\n" ;
  $x = 78 ;
  print "\$x=$x.  d(\$x) + \$x: " ;
    print o(d($x), 'LHS ') + o($x, 'RHS '), "  \$x=$x\n" ;
[download]

I get:

  $x=78.  $x + d($x): LHS RHS 79  $x=10
  $x=78.  d($x) + $x: LHS RHS 11  $x=10

which could, of course, be the effect of introducing an observer into the system... but more likely due to the actual copying of the value of $x, which the simpler expression is optimising away.

Well, there you go. No matter how tightly one tries to bind one's abstract model to the implementation, there's always something !