English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
ambitious proposal: polymorphic arithmetics
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2005-04-06 (19:34)
From: Eijiro Sumii <eijiro_sumii@a...>
Subject: Re: [Caml-list] ambitious proposal: polymorphic arithmetics
From: "William Lovas" <wlovas@stwing.upenn.edu>
> More seriously, one might argue -- only slightly hand-wavily -- that with
> =, <, etc., types whose values *cannot* be used as inputs are the exception
> rather than the rule, whereas the reverse is the case for +, -, etc.  For
> example, it may be perfectly clear (or at least possible to specify) how to
> implement comparisons on data types, records, and tuples.  What should the
> arithmetic operators mean on such things?

I don't quite think comparisons are clearer (or "more possible" to
specify) than additions for tuples and records - they can be defined
just element-wise.  Data types indeed seem more problematic as pointed
out in other replies.

> (This argument breaks down in
> the face of code which relies on abstract types to enforce modularity -- in
> such cases, incomparability can become "the rule" rather than the
> exception, putting =, <, etc. on the same footing as +, -, etc.)

Yes, polymorphic comparison already breaks type abstraction.