On Sun, Nov 06, 2005 at 03:10:40PM +0100, Ingo Blechschmidt wrote: : Hi, : : my ($key, $value) = <key val>; : my $pair = ($key => $value); : : $pair.key = "new"; : # Should this fail ("cannot modify a constant")? : # Should this update $pair.key, but leave $key untouched? : # Should this update $pair.key, implicitly updating $key as well?
#2. => copies $key, or equivalently does COW. : $pair.value = "new"; : # Should this fail ("cannot modify a constant")? : # Should this update $pair.value, but leave $value untouched? : # Should this update $pair.value, implicitly updating $value : # as well? Likewise #2, I think. Also, if we provide a way to return a pair instead of a value from a hash (currently done with the new :%hash<key> syntax), then we can't have people trying to modify the key of the hash in place unless there's some way to notify the hash that it has to re-insert the new key, and that sounds like a big bother for little gain. : If setting $pair.value changes $value, should rebinding $pair.value : cause the binding to get destroyed: : : $pair.value := $some_other_var; : $pair.value = "new"; : # $value unchanged, $some_other_var set to "new" : : If setting $pair.value does not change $value, should binding : $pair.value to $value do what I mean: : : $pair.value := $value; : $pair.value = "new"; : # $value changed I think binding directly to .key or .value is different from what => does. So after $pair = $key => $value; setting $value doesn't change $value, but after $pair.value := $value it does. We could have an => equivalent that does binding rather than copying: $pair = $key :=> $value; Of course, that *looks* like we're only binding the key side, so we could go with $pair = $key :> $value; or $pair = $key ::> $value; Doubtless if we added that, we'd get requests to only bind the key or the value: $pair = $key ::> $value; # bind both $pair = $key :=> $value; # bind the key $pair = $key =:> $value; # bind the value These have interesting ramifications when reduced: $cons = [::>] @list; $cons = [:=>] @list; $cons = [=:>] @list; Probably we'd want to optimize the value-copying variants to not recopy the tail of the list at each step if possible. I suppose an argument could be made for => to default to =:>. In Haskell the correct answer is always ::>, of course, but Haskell doesn't easily admit to the existence of mutable values. I think our pairs are containers, not values. Maybe \(key => $value) is how you turn => into ::>, since in the case of an arglist you have to be able to bind to the original $value. Or maybe :> is our named arg syntax and => is always a pair. Larry