Browse thread
ambitious proposal: polymorphic arithmetics
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| 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. Eijiro