caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: William Lovas <wlovas@stwing.upenn.edu>
To: caml-list@inria.fr
Subject: Re: [Caml-list] ambitious proposal: polymorphic arithmetics
Date: Wed, 6 Apr 2005 12:39:16 -0400	[thread overview]
Message-ID: <20050406163915.GC15547@force.stwing.upenn.edu> (raw)
In-Reply-To: <20050406.111505.68543084.eijiro_sumii@anet.ne.jp>

Hi Eijiro,

On Wed, Apr 06, 2005 at 11:15:05AM -0400, Eijiro Sumii wrote:
> So here it goes: why don't we have polymorphic +, -, etc. while we
> have polymorphic =, <, etc.?  Many novices and (at least) some experts
> feel that +., -., etc. are not quite nice.  Why not define +, -,
> etc. for as many types as possible such as integers, floating-point
> numbers, and tuples?  I think they can be implemented almost in the
> same efficient way as =.  They can also raise an exception if applied
> to unsupported values such as functions, just as = does.

Many experts (and perhaps some novices *shrug*) think that polymorphic
equality is a bad idea... so maybe it's best to just leave "well enough"
alone :)

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?  (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.)

These are just my thoughts, though, and i'm still something of a nameless
student :)

cheers,
William


  parent reply	other threads:[~2005-04-06 16:39 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-06 15:15 Eijiro Sumii
2005-04-06 15:51 ` [Caml-list] " Sébastien Hinderer
2005-04-06 15:56 ` Richard Jones
2005-04-06 16:43   ` Dmitry Lomov
2005-04-06 18:59     ` Richard Jones
2005-04-06 19:19       ` Jacques Carette
2005-04-07  0:01       ` Ethan Aubin
2005-04-06 16:39 ` William Lovas [this message]
2005-04-06 16:59   ` [Caml-list] " Andreas Rossberg
2005-04-06 18:50   ` Eijiro Sumii
2005-04-06 19:33   ` Eijiro Sumii
2005-04-07  0:13     ` William Lovas
2005-04-07  1:58       ` Jacques Garrigue
2005-04-06 17:00 ` Christophe TROESTLER
2005-04-06 19:20   ` Eijiro Sumii
2005-04-07 14:00     ` Christophe TROESTLER
2005-04-06 17:23 ` Marcin 'Qrczak' Kowalczyk
2005-04-06 18:01   ` padiolea
2005-04-06 19:14     ` Eijiro Sumii
2005-04-06 20:31       ` Eijiro Sumii
2005-04-06 21:53         ` Marcin 'Qrczak' Kowalczyk
2005-04-06 22:38           ` Eijiro Sumii
2005-04-06 19:23     ` Richard Jones
2005-04-09  2:58 ` Jon Harrop
2005-04-09  3:16   ` Eijiro Sumii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050406163915.GC15547@force.stwing.upenn.edu \
    --to=wlovas@stwing.upenn.edu \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).