Re: polymorphic equality and overloading

[Eijiro Sumii <sumii@saul.cis.upenn.edu>]

> 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