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
