> Luke Palmer <[EMAIL PROTECTED]> writes:
>
> > However, my problem remains. What does the poor generic programmer do
> > when he needs generic equality!?
>
> unfortunetly, no such thing exists.
>
> see:
>
> http://xrl.us/fdz
>
> and
>
> http://www.nhplace.com/kent/PS/EQUAL.html
>
> although the specifics are common lisp related the underlying ideas
> are equally valid to perl.
Thanks! I was pondering what "generic equality" meant, thinking I know
something I don't.
However, I'm taking from C++ (my favorite language for generic
programming, but not much else) in which std::map requires the keyed
type to define < and == (or provide them in the template arguments).
And indeed, a binary-tree map can't work without those operations.
But C++ has it easy, because every variable must have exactly one
type, at compile time. And all types in the map are the same. It's a
tough call which == you would call when you have one for (Str,Str) and
one for (Int,Int) and are given (Str,Int). In fact, an ambiguous call
that ought to be an error.
So "generic equality" is^H^Hmust be overloaded in order to function.
It's the one that the user wants his/her classes to obey when put in
generic containers and algorithms. And it may differ from application
to application. (It may differ from container to container, and
that's why there's parameterized types. But we can't expect the lazy
Perl programmer to specify explicitly each time a container is used.)
So, I guess what I'm saying is that this "generic equality" isn't the
super-operator that always knows what you mean, it's the default
operator that does whatever you think the best thing is. And you tell
it what the best thing is. That's the idea.
And what happens if it's given two incompatible types? It would call
the multimethod that matched them, or it would just return false. No,
a Cat isn't a String, no matter what's inside them.
Maybe smart-match I<is> what we want, and maybe it shouldn't be quite
so dwimmy. For instance:
given 13 {
when (12,13,14) {...}
}
Why would you say that when you could say:
given 13 {
when any(12,13,14) {...}
}
Say What You Mean. The former just wouldn't match, because 13 isn't
equal to the list (12,13,14).
This comes back to many kinds of equality. Who says that two arrays
should match if there is some intersection of their values? Somebody
might want them to match if *all* of the values of the second are
contained in the first. Again:
given any(1,2,3,5,6) {
when all(2,3) ~~ $_ {...}
}
(The ~~ $_ is necessary because of junction nesting, I think)
or
given (1,2,3,5,6) {
when all(2,3) ~~ any([EMAIL PROTECTED]) {...}
}
Say What You Mean again.
Plus, then you could do things like indexing into containers with
regexen, and getting out objects that match. Junctions make the
complex cases that ~~ addresses rather trivial. They make them read
better, too.
Luke
