--- Damian Conway <[EMAIL PROTECTED]> wrote:
> Date: Wed, 28 Jan 2004 12:34:15 +1100
> From: "Damian Conway" <[EMAIL PROTECTED]> Add to Address Book
> To: "Language List" <[EMAIL PROTECTED]>
>Subject: Re: Semantics of vector operations (Damian)
Messages are *not* guaranteed to arrive in the order sent, but boy,
this seems harsh!
> I have trouble with junctive lvalues because I think they lead to
> unexpected/unpredictable behaviour. For example, the "predicate"
> associated with a junction is only invoked when that junction is
> involved in a boolean test of some kind, so the (hypothetical):
>
> all($x, $y, $z) = 1;
> any($x, $y, $z) = 1;
> one($x, $y, $z) = 1;
> none($x, $y, $z) = 1;
>
> would (hypothetically) all do the same thing (i.e. independently
> assign 1 to each of the three scalar variables).
> That makes the last three versions nothing but obfuscatory in
> my view.
Perhaps we could consider the junctive lvalues as a sort of implied
?= operation:
junction(@list) = value
means
unless junction(@list) == value
{
given junction {
when 'none' { (@list.grep value) = undef; }
when 'any' { for 0 .. random(@list) { @list[random(@list)] =
undef; } }
when 'one' { @list[random(@list)] = undef; }
when 'all' { @list = $(@list) x undef; }
}
}
(which would make for some interesting use cases around 'any', at least
;-)
=Austin
>
> So, at very best, we'd have to restrict lvalue junctions to
> conjunctions.
>
> And there seems to be very little benefit even in that restricted
> form,
> especially when you consider that:
>
> all($x, $y, $z) = 1;
> all(@foo) = 2;
>
> are hardly any better than the existing solutions:
>
> $x = $y = $z = 1;
> $_ = 2 for @foo;
>
> and no better at all than the Perl 6 distributive solutions:
>
> ($x, $y, $z) �= 1;
> @foo �= 2;
>
> So, on balance, I feel that lvalue junctions are more trouble than
> they're worth.
>
>
> Damian
>
>
>
>
>
