On 9/8/05, Damian Conway <[EMAIL PROTECTED]> wrote:
> Luke wrote:
>
> > Okay, fair enough. The reason that I thought it was surprising is
> > because 1 and 2 are usually orthogonal patterns.
>
> It depends what they're doing. Matched against a regex like /[12]/ they're
> not orthogonal either.
Well, then they're not patterns; they're the things being matched
against a pattern. But then you could think of junctions in the same
way. In fact, the proposal was to do precisely that. But I think
you've knocked me off of that one (with your "multiple junctions in
the same expression" examples).
> > that was a logical statement explaining that junctions are not logical.
>
> Riiiiiiiiight. So "Luke's statement is a logical travesty" isn't an
> unsubstantiated emotive assertion either? ;-)
Hey. I backed up my claim with a proof! Let's settle on "It doesn't
matter!" :-)
> >> if ! defined one(@inputs) {...}
> >
> > I don't get how this could possibly be useful.
>
> That doesn't mean it's not. ;-)
You don't need to sell me on these, by the way. You already did.
That was just a comment on this particular example.
> > 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!
>
> You can rest assured that I won't try to make one. Because it doesn't
> makes *sense* to even talk about an ordered set of junctions. Any more
> than it makes sense to talk about an ordered set of vectors, or lists,
> or regexes. Will you also be recommending that lists and regexes not be
> values???
Well, none of those things define a < operator. I suppose one could
say that lists do, but he'd be wrong. They coerce to numbers, which
in turn have a < operator, so you'd end up with a set of numbers...
I think I see where you're coming from though. If we go with
Haskell's type classes, then I could see how this would work.
Junction simply wouldn't do Eq or Ord (equality or ordering), since it
doesn't meet the prerequisites for doing those type classes
(transitivity and antisymmetry). Then the Junctive > would be about
as similar to numeric > as IO::All's > is, at least from Perl's
perspective.
> More seriously, since the ordered set's methods presumably *won't* use
> (Item(+)Junction) type arguments, why will this be a problem? The
> ordered set will never *see* junctions.
Set of Junction? If the methods are declared with parameters ::T (the
parameterization type of Set), then it certainly would accept
junctions.
Admittedly, that should just fail since it doesn't make any sense.
Admittedly, it would probably end up succeeding and giving you an
infinite loop, and then comp.lang.perl.misc or #perl would give you a
belated compile-time error. Or Set could say "No junctions!", but
then we're getting into special cases.
Hmm, incidentally, if we have:
theory Value[::T] {
# in order to do Value, eqv must be transitive:
# $a eqv $b and $b eqv $c implies $a eqv $c
multi infix:<eqv> (::T, ::T --> Bool) {...}
# ... some useful methods
}
(For those of you following along at home, don't worry if you don't
know what a "theory" is, I haven't proposed it yet. For those of you
lambdacamels following along at home, a "theory" is basically a type
class.)
Then Junction shouldn't do Value, since it doesn't meet one of the
implicit requirements. Since Sets only operate on Values (no
reference types allowed: they can change under your feet), then a Set
would reject a Junction as a valid parameterization. Oh, I guess
Junction's absence of the Ordered class already did that.
Alright, this seems to be working out mathematically if we get type
classes. It's really not a solution I like much, as it's basically
saying "yeah, junctions exist, but they really don't participate in
the algebra of your program". Actually, since they don't do Value,
you can't make any aggregate of Junctions whether you declare it or
not (sub parameters are still okay when declared though; they don't
have to be Values).
Okay, with that, my position changes. I no longer see anything wrong
with Junctions from a pure perspective. I still think it's wrong to
Humans to have something that looks ordered but in fact isn't, and I
still think that if Junctions are values, you ought to be able to
metaprogram with them. But I don't really have any ideas other than
the ones I've proposed in this thread and the one involving Haskell's
"M" word.
Luke
