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 XAA08669 for caml-red; Wed, 5 Jul 2000 23:26:04 +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 DAA17276 for ; Wed, 5 Jul 2000 03:12:31 +0200 (MET DST) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by nez-perce.inria.fr (8.10.0/8.10.0) with ESMTP id e651CTf19161 for ; Wed, 5 Jul 2000 03:12:30 +0200 (MET DST) Received: from localhost (sansho.kurims.kyoto-u.ac.jp [130.54.16.90]) by kurims.kurims.kyoto-u.ac.jp (8.9.3/3.7W) with ESMTP id KAA13570; Wed, 5 Jul 2000 10:12:13 +0900 (JST) To: sumii@saul.cis.upenn.edu Cc: caml-list@inria.fr Subject: Re: polymorphic equality and overloading In-Reply-To: Your message of "Tue, 04 Jul 2000 08:42:24 -0400" <20000704084224R.sumii@saul.cis.upenn.edu> References: <20000704084224R.sumii@saul.cis.upenn.edu> X-Mailer: Mew version 1.93 on Emacs 20.5 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000705101152P.garrigue@kurims.kyoto-u.ac.jp> Date: Wed, 05 Jul 2000 10:11:52 +0900 From: Jacques Garrigue X-Dispatcher: imput version 980905(IM100) Sender: weis@pauillac.inria.fr 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