Patrick R. Michaud wrote:
>>$x = $Value | 'Default';
>> instead of :
>>$x = $Value || 'Default';
>
>
> Hmm, this is an interesting point. I'll let others chime in here,
> as I don't have a good answer (nor am I at all authoritative on junctions).
This is merely syntax; it doesn't really have anything to do with junctions
per se.
Besides which, both those syntaxes are *already* valid in Perl 5. And yet
people don't commonly make this mistake now. Why would they make it more
frequently when | produces a junction instead?
We see very few C<$x * $y> vs C<$x ** $y> mistakes. We see very few C<-$x> vs
C<--$x> mistakes. And when C<//> becomes a valid Perl 5 operator (in 5.10)
we're not fearfully anticipating a flood of:
$x = $Value / 'Default';
instead of :
$x = $Value // 'Default';
errors.
> Ultimately I don't think I agree with the notion that sets and lists
> are so different, or that sets deserve/require their own sigil.
Sets shouldn't have a sigil anyway, whether they're qualitatively different
from lists or not. A set is a *value* (like an integer, or a string, or a
list). A set is not a *container* (like an scalar or an array). And only
containers get sigils in Perl.
> Certainly a list can be used to represent a set, and we can easily
> define intersection/union/subset operations for lists, or else just
> define a Set class and put the operations there. Getting a list
> to have unique values seems easy enough
>
> @xyz = all(@xyz).values(); # remove any duplicate elements of @xyz
BTW, I'm pretty sure there will be built-in C<Array::uniq> and C<List::uniq>
methods in Perl 6. So that's just:
@xyz = uniq @xyz;
or better still:
@xyz.=uniq;
Damian
Thread Previous
|
Thread Next