Rod Adams wrote:
> I would argue that this sort of relational comparison is of limited
> usefulness.
Well, except junctions hold more information than the simple comparisons
I've given here. For example, a junction can have a value like:
$x = ($a & $b) ^ ($c & $d)
which is true only if $a and $b are true or $c and $d are true but not
both.
> Invariably, the next question that will nearly always be
> asked is "_Which_ values worked / didn't work?".
If you're wanting to know *which* values worked, we still have C<grep> --
we don't need a special set notation for it, or to worry about junctions.
> so, where you say:
> if any(1,2,3,4) <= 3 {...}
> I would have a bit more complex:
>
> if (1,2,3,4) & {$^a <=3} {...}
if grep {$^a <= 3} (1,2,3,4) { ... }
> however, I could also say:
>
> if ((1,2,3,4) & {$^a <=3}).elems > 2 {...}
if (grep {$^a <= 3) (1,2,3,4)) > 2 { ... }
> for (1,2,3,4) & {$^a <=3} -> $a { ... }
>
> Assuming that the {$^a <= 3} is some sort of meaningful threshold, one
> would likely have defined a virtual set for it, so that becomes:
>
> for (1,2,3,4) * #threshold -> $a { ... }
Ummm, out of curiosity, what would #threshold look like here?
> [...] And how utterly impossible is it going to
> be to debug a program that gets an inadvertent junction/set thrown in
> somewhere. Like:
>
> $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).
> and((2,3,4) �<= 3)
>
> btw, I like and()/or() over all()/any() because it makes it very clear
> we are establishing a boolean context.
To me the fact that we're using <= establishes that we're interested
in a boolean result; I don't need "and/or" to indicate that. Using
"and" to mean "all" doesn't quite work for me, as I somehow think of
"and" as a two-argument operation.
> [intersection]
> #foo * #bar # and we even know which ones!
>
> [containment]
> #foo <= #bar
>
> [non-intersection]
> !(#foo * #bar)
Somehow overloading C<*> to mean "intersection" just doesn't work for
me here. I'd have to think about it.
> But what happens when you try to escape the boolean context? I'll
> reiterate my autothreading concerns above.
> And in these, you still have to do something completely different to
> determine what the factors are.
...and we can still do those different things using grep and the
other list-context operations at our disposal.
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.
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
so I'm not sure I see the need for a separate type.
Anyway, hopefully some others who have more experience than me on
this can chime in if appropriate.
Pm
