caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Mike Lin <mikelin@MIT.EDU>
To: Michal Moskal <malekith@pld-linux.org>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Understanding why Ocaml doesn't support operator overloading.
Date: Sat, 30 Nov 2002 18:06:44 -0500	[thread overview]
Message-ID: <653C1EDB-04B8-11D7-89AB-000393AE4242@mit.edu> (raw)
In-Reply-To: <20021130102400.GA2705@roke.freak>

>
> No. Compiler trates polymorphic types as abstract then. It need not 
> know
> what is the exact type, all it cares about is size of data, which in
> case of OCaml on 32 bit machines is always 4 bytes.
>
> For example in:
> .......

Fair enough. I'm curious though: Say I'm the programmer and I would 
like to solve the problem of combining different types of numbers with 
a fairly uniform syntax. I'm either going to define a union type for 
numbers and have all my functions pattern-match, or else I'm going to 
write several versions of my functions to handle different types of 
numbers and call different ones as appropriate. I would wish that if 
all my functions were built up from the primitives +, -, *, /, etc. the 
compiler could do this for me. The compiler may have to generate many 
different versions if I use them all, but otherwise I would have to 
write them myself!

I don't think this whole thing is a good idea in general, but I don't 
buy this practicality/efficiency argument against it.

>
> Again: Haskell does it, so typing isn't real issue here.

Haskell also does not have mutable data, and I think it has been well 
established in the literature that mutable data complicates subtyping 
and intersection typing. So, as others are pointing out, I definitely 
think typing is a real issue here.

-Mike

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners


  reply	other threads:[~2002-11-30 23:06 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-11-28 21:02 Jørgen Hermanrud Fjeld
2002-11-28 21:27 ` Jørgen Hermanrud Fjeld
2002-11-29 15:26 ` Xavier Leroy
2002-11-29 15:42   ` Christophe Raffalli
2002-11-29 16:52   ` Nicolas Cannasse
2002-11-29 17:26     ` Michal Moskal
2002-11-30  0:00       ` Mike Lin
2002-11-30 10:24         ` Michal Moskal
2002-11-30 23:06           ` Mike Lin [this message]
2002-11-30 21:41         ` William Lovas
2002-12-01 17:30           ` Pierre Weis
2002-12-01 23:41             ` William Lovas
2002-12-02  9:52               ` Remi VANICAT
2002-11-30 21:47         ` Pierre Weis
2002-12-01  7:40           ` Christophe Raffalli
2002-11-30 21:36       ` Pierre Weis
2002-11-30 21:33     ` Pierre Weis

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=653C1EDB-04B8-11D7-89AB-000393AE4242@mit.edu \
    --to=mikelin@mit.edu \
    --cc=caml-list@inria.fr \
    --cc=malekith@pld-linux.org \
    /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).