From mboxrd@z Thu Jan  1 00:00:00 1970
Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id XAA02730 for caml-red; Wed, 5 Jul 2000 23:22:39 +0200 (MET DST)
Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id OAA07419 for <caml-list@pauillac.inria.fr>; Tue, 4 Jul 2000 14:42:41 +0200 (MET DST)
Received: from dynabook.is.s.u-tokyo.ac.jp (esumii-dsl-gw.dca.net [216.158.25.176])
	by nez-perce.inria.fr (8.10.0/8.10.0) with ESMTP id e64Cgef09971
	for <caml-list@inria.fr>; Tue, 4 Jul 2000 14:42:40 +0200 (MET DST)
Received: from localhost ([127.0.0.1])
	by dynabook.is.s.u-tokyo.ac.jp with esmtp (Exim 3.12 #1 (Debian))
	id 139S1x-0006Wp-00; Tue, 04 Jul 2000 08:42:25 -0400
To: garrigue@kurims.kyoto-u.ac.jp
Cc: sumii@saul.cis.upenn.edu, caml-list@inria.fr
Subject: Re: polymorphic equality and overloading
In-Reply-To: <20000704160900Z.garrigue@kurims.kyoto-u.ac.jp>
References: <20000630135105Q.sumii@saul.cis.upenn.edu>
	<20000704160900Z.garrigue@kurims.kyoto-u.ac.jp>
X-Mailer: Mew version 1.94.1 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000704084224R.sumii@saul.cis.upenn.edu>
Date: Tue, 04 Jul 2000 08:42:24 -0400
From: Eijiro Sumii <sumii@saul.cis.upenn.edu>
X-Dispatcher: imput version 991025(IM133)
Sender: weis@pauillac.inria.fr

> 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