On 1/4/06, Jonathan Lang <[EMAIL PROTECTED]> wrote:
> > And I'm almost sure that I agree with him. It's too bad, because
> > except for that little "detail", fmap was looking pretty darn nice for
> > junctions.
>
> Not really. If I read the fmap proposal correctly,
You didn't :-)
> if any($x, $y, $z) »==« any(1, 2, 3) {...}
>
> would do the same thing as
>
> if $x == 1 || $y == 2 || $z == 3 {...}
The key point is that >>==<< just threads == through the (binary in
this case) functor, and it's up to the functor to decide what that
means. For lists:
(1,2) >>+<< (3,4) === (4,6)
But for junctions:
1|2 >>+<< 3|4 === 4|5|5|6 === 4|5|6
The thing that makes lists "zip-thread" is the definition the
Functor{List} instance, not anything fundamental about functors.
> Side note: "any(1, 2, 3)" is indistinguishable from "one(1, 2, 3)",
> because the values 1, 2, and 3 are mutually exclusive.
That's only true when you're thinking about equality:
1 < any(1,2,3) # true
1 < one(1,2,3) # false (1 < 2 and 1 < 3)
People often
> use the inclusive disjunction when they mean the exclusive one, and
> get away with it only because the values that they're dealing with are
> mutually exclusive. Another issue is that one-junctions conceptually
> represent a single value at a time - though which one is unknowable -
Junctions are frightfully more abstract than that. They only take on
meaning when you evaluate them in boolean context. Before that, they
represent only a potential to become a boolean test. You could think
of them like an "operator voltage": a comparison divided by the
operator and one of the operands.
Luke
