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
next prev parent 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