Re: polymorphic equality and overloading

[Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>]

Hello Eijiro,

Your answer seems to be a little twisted from mine (and mine might
have been so too).

The point I was trying to make is just that Ocaml, to avoid
complications in the type system, only allows universal overloading,
that is overloaded operators which are defined at all types, and with
minimal runtime support (in practice little more than what would be
strictly necessary for the GC).

Comparison, hashing and marshalling are thus defined on almost
everything, with notable exceptions like functions, and C values when
no custom operations are provided.

I think hashing and marshalling will not bother you: they are not
expected to have any particular meaning, other than being reversible
(for marshalling) and fulfill a few properties (for hashing).

I really believe comparison (not only equality) must be understood in
the same way: operations that make easier to use some data structures.
Comparison may not be always the one you expect, but in practice this
is enough to define efficient sets and maps. It is the finest grain
relation available (without using physical equality), so that you will
have to define you own comparison if you need something coarser
(or a different order, but again generic comparison is not really
intended to give you the best order).  But it is meaningful (it
has some meaning) and useful (it has some uses).

Now the discussion is rather that having such "arbitrary" comparison
may be confusing. You see sometimes messages on the caml-list coming
from misunderstanding generic comparisons, on rationals for instance.
There is a tradeoff between simplicity and intuition.
I don't know why the choice has been so in Caml, but there are good
reasons on both sides.

Haskell's solution may seem more intuitive, but it uses a much more
complex type system, and puts the burden of writing comparisons on the
user. This is partly automatized, but with just the same problems you
indicated for Caml: the default definition of comparison may not be
the one you want.

Jacques

> > The answer is in your sentence: how do you define addition on tuples ?
> 
> Just in the same way as equality is defined: element-wise.  Such
> automatically defined "polymorphic addition" may not make sense, but
> neither may the automatically defined polymorphic equality.  For
> example, the polymorphic equality doesn't make sense for fractions
> represented as tuples of a denominator and a numerator, polynomials
> represented as lists of coefficients, complex numbers represented as
> tuples of a magnitude and an angle, etc.
> 
> > Or even on strings: ^ is not addition but concatenation;
> > fun s1 s2 -> string_of_float (float_of_string s1 +. float_of_string s2)
> > will give you a very different result.
> 
> So will "fun s1 s2 -> string_of_float (float_of_string s1 =
> float_of_string s2)" too.
> 
> > The only form of overloading currently accepted in Caml is universal
> > overloading, that is operations available at all types.
> > Comparison is just "naturally" defined on almost anything,
> 
> As I wrote above, I'm wondering whether the "naturally defined"
> polymorphic (in)equalities make more sense than the element-wise
> defined polymorphic addition.
> 
> > There is some arbitrary part in this definition, but even so
> > being able to compare values is useful anyway (Set and Map modules).
> 
> Again, I doubt how often polymorphic (in)equalities work---for
> instance, what if one represents a finite partial function "f" from
> complex numbers (in the polar representation) to booleans, define "f
> (0.0, 0.0)" to be true, and define "f (0.0, pi)" to be false using the
> Map module?
> 
> > I do not really see what would be the use of an underspecified
> > addition on algebraic datatypes, for instance.
> 
> Neither do I, and I also don't see whether the polymorphic
> (in)equalities are more useful than the "polymorphic addition".  That
> was (and is) my question.
> 
> Eijiro