On 9/7/05, Damian Conway <[EMAIL PROTECTED]> wrote:
> Luke wrote:
> > In that last case though, this is not equivalent to the above:
> >
> > given &code.arity {
> > when 2 { code(1,2) }
> > when 1 { code(1) }
> > }
> >
> > That may be a little... surprising. Still, it's fixed to succeed
> > either way, so that's probably okay, right?
>
> It's not surprising at all. The order of C<when> tests (usually) matters,
> because a series of C<when> statements (usually) short-circuits.
Okay, fair enough. The reason that I thought it was surprising is
because 1 and 2 are usually orthogonal patterns. But, I guess in the
presence of junctions I'm not able to assume that (as I'll explain in
my conclusion later, junctions make it impossible for me to assume
just about anything).
> > Junctions are logical travesty,
>
> Well, that's very emotive, but I don't believe it's either a useful or an
> accurate characterization. I would agree that junctions can be logically
> *sophisticated*, but then I'd argue that *all* programming constructs are
> that.
No, that wasn't emotive, that was a logical statement explaining that
junctions are not logical. Maybe that's what I should have said
before. See below.
> > and it seems to me that they cease to be useful in all but the
> > situations where the coder knows *everything*.
>
> What does that mean, exactly? How can anyone *ever* write sensible code
> without knowing what kind of values they're processing?
Have you ever heard of generic programming?
How can any *ever* write a sensible generic Set class when you are
required to know what kind of thing you have in the set?
> Otherwise hard things that junctions make a lot easier:
>
> if 0 <= @coefficients < 1 {...}
Ummm... that's an array in numeric context...
> if 0 <= all(@new_coefficients) < all(@prev_coefficients) < 1 {...}
I'll give you this one. This takes twice the amount of code.
if 0 <= min(@new_coefficients) &&
max(@new_coeffficients) < min(@prev_coefficients) &&
max(@prev_coefficients) < 1 {...}
> if 0 <= all(@new_coefficients) != all(@prev_coefficients) < 1 {...}
>
> if 0 <= any(@new_coefficients) != all(@prev_coefficients) < 1 {...}
Okay, you may be convincing me here. Until I find a good way to do
these. The fact that I have to look is already junctions++.
> if ! defined one(@inputs) {...}
I don't get how this could possibly be useful.
> > $a <= any($a, $b).
> > any($a, $b) <= $b.
> > Therefore, $a <= $b.
...
> Luke is no smarter than Luke or Luke is no smarter than a rock.
> Luke is no smarter than a rock or a rock is no smarter than a rock.
>
> Remove the false assertions (since nothing correct can ever be deduced
> from a false assertion):
Sure, everything correct can be deduced from a false premise. Just...
um... everything incorrect can too. :-)
> Luke is no smarter than Luke
> a rock is no smarter than a rock.
>
> But now the remaining assertions support *no* new conclusion.
And this is based on lexical expansion. Which is cool. In fact, once
upon a time I was going to propose that junctions are a purely lexical
entity, expanded into greps and whatnot by the compiler; that you
can't ever stick them in variables. Your examples above are just more
attestment to that, since there is not one of them that I can't write
confining all junctions to lexical areas.
I think you missed my original point. Here is a similar proof:
Assume for the sake of contradiction that:
For all $a,$b,$c:
$a < $b && $b < $c implies $a < $c;
let $a = 3, $b = any(1,4), and $c = 2
Substituting:
3 < any(1,4) && any(1,4) < 2 implies 3 < 2
True implies False
Contradiction!
I just proved that < is not transitive.
I can do that for every boolean operator that Perl has. They no
longer have any general properties, so you can't write code based on
assumptions that they do. In particular, testing whether all
elements in a list are equal goes from an O(n) operation to an O(n^2)
operation, since I can't make the assumption that equality is
transitive.
So my original point was that, as cool as junctions are, they must not
be values, lest logical assumptions that code makes be violated. I
can tell you one thing: an ordered set class assumes that < is
transitive. You had better not make an ordered set of junctions!
Luke
