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
