/msg BrowserUk Turn on your chatterbox nodelet

My point (which includes a smiley) is that the left-hand side should be evaluated enough to give us full context (including how many slots we will be assigning into) before the right-hand side code is run in that context.

/msg tye Sorry. I forgot how to.

It sounds like your arguing for defining the execution order?

If so, (apart from that I doubt it will ever happen), then I'd have to argue for the right-hand side of the = always being fully evaluated before the left-hand side is even considered, with the exception of context.

Now I realise that there is some precedent for at least partially evaluating the left-hand side with split.

( $one, $two, $three ) == split '', huge_megabyte_scalar;
[download]

makes good use of this to avoid a lot of work and memory.

But if it is

$#a = 10;
@a = split'', $huge_long scalar;
[download]

that doesn't (and couldn't) limit the split.

In the first case, the knowledge of the left-hand side used in evaluating the right-hand side is purely an optimisation--effectively, extended context--which doesn't change the semantic outcome of the statement. Only the performance.

In the case of

@hash{ listGenerator() } = ....;
[download]

pre-determining the affected slice of the hash prior to evaluating the right-hand side of the assignment can distinctly change the semantics which I think will always be a bad thing.

While I'd prefer clearly defined orders of evaluation, if it happened, then the right-hand side of assignment should always be (fully) evaluated before the left-hand side, except for those rare semantically benign situations where extend contextual information results in transparent optimisations.

Any situation where predetermined context or sub evaluation could actually determine the outcome of the statement, as would be the case if the range expression in

@hash{ 1 .. keys %hash } = delete @hash{ listGenerator() };
[download]

was done prior to the delete, would be a nightmare.

---

Examine what is said, not who speaks.

"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
"Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon

In the first case, the knowledge of the left-hand side used in evaluating the right-hand side is purely an optimisation--effectively, extended context--which doesn't change the semantic outcome of the statement.

quibble: it does change the semantic outcome. The game is judged to be worth the candle, though. Example:

use Data::Dumper;
my ($a,$b,@a);
($a,$b) = split / /, "a ";
print Dumper $a,$b;
($a,$b) = @a = split / /, "a ";
print Dumper $a,$b;
[download]

Without the optimization, the default removal of trailing empty fields leaves $b undefined.

I'm not sure what strange interpretation you are doing.

In the first case, the knowledge of the left-hand side used in evaluating the right-hand side is purely an optimisation--effectively, extended context--which doesn't change the semantic outcome of the statement. Only the performance.

And that's all I'm talking about doing.

Your split example makes no sense. Here's an example that makes sense:

my @h;
my @i= (0..1);
@h[@i]= split / /, "This is a test case";
print "(@h)\n";
__END__
Output:
(This is)
[download]

The only difference with my proposed change is that split can be optimized in this case. No difference in output.

You'll have to actually describe how you thought I was proposing that refined context change outcome. I'm proposing that the evalation order be changed which would change the results of statements that depend on the evaluation order, obviously. But the refinement of the "context" from "list, unspecified size" to "list, size of $N" for those rare operations that care about such things is part of the justification for this change, not something that will change outcomes itself.

- tye