Trey Harris skribis 2006-09-01 0:17 (-0700):
> I think these semantics are Almost Right, but yet Entirely Wrong. The
> problem is that C<but> reads to me as a *mutating* operator. That is, I
> would expect the above code snippet to give me a C<$z.y> of 17, but leave
> C<$p.y> as 0. Surely this is what one would expect from analogy of
In the terminology that I have been using, that would not be a mutating
operator, but a copying operator, exactly because the operand $p remains
untouched.
mutating:
sub foo ($foo is rw) { $foo = sqrt($foo) }
foo($bar);
$baz ~~ s/foo/bar/;
copying:
sub foo ($foo is copy) { $foo = sqrt($foo) }
foo($bar);
$baz.subst(/foo/, "bar");
> But yet C<but> with a closure doesn't copy, given the translation above,
> or even allow modification, since C<given> doesn't either. $_ (in the
> above case, $p) is set to point to the same object, and so $p.y and $z.y
> are both modified (or rather, they both refer to the same object, which is
> modified during assignment).
> In other words, I would actually expect
> $x but { ... }
> to translate to
> do given $x -> $_ is clone { ...; $_ }
Agreed that this would be much more useful.
> where C<is clone> is a conjectural way of calling .clone if the argument
> is an object type but reduces to C<is copy> if the argument is a value
> type.
Oh, I like "is clone" with these semantics. Though everything is an
object, so you'd need a different explanation...
> I do not think that C<but> should mutate its LHS, regardless what its RHS
> is.
Agreed, and that's why "$foo but s///" would be a reasonable replacement
for what's currently still "$foo.subst(//, '')". subst doesn't mutate.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
