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

On Fri, Nov 29, 2002 at 07:00:21PM -0500, Mike Lin wrote:
> >The problem is what *assembly code* should be generated for function f?
> >Code to add 2 integers or code to add 2 floats? Hmm.. we'll have a
> >problem then. Or maybe both? And choose versions of f based on type it
> >is applied to? But then consider:
> >
> >let f x1 x2 ... xn = ((x1 + x1), (x2 + x2), ..., (xn + xn))
> >
> >you need to generate 2^n versions of f. We're getting to ugly things
> >like C++ templates here.
> 
> If this is really a problem then what gets generated when you write any 
> polymorphic function at all? 

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:

let f g x = g x x

f ( + ) 1
f ( +. ) 1.0

There is no problem for the compiler. It can genarate code for f like:

void *f(void *(*g)(void *, void *), void *x)
{
	return g(x, x);
}

However for:

let f x = x + x

it needs to generate something like:

void *f(void *x)
{
	if (is_integer(x))
		return x + x;
	else
		return box(unbox(x) +. unbox(x));
	// unbox(x) == *(double*)x
	// box(x) allocates double on the heap and returns pointer to it
}

and this runtime check has significant perfomance impact. I guess
Haskell does it.

> The proposal is to allow constrained 
> polymorphism; the polymorphism that is already in OCaml seems to 
> supersede this with regard to the above objection.
> 
> I wonder if the unification algorithm can be generalized to intersect 
> sets of allowable types instead of unifying "for all" type variables. 
> It doesn't seem too ludicrous in principle but I could easily have 
> missed some nasty corner case.

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

I guess overloading could be resolved efficiently using some kind of
runtime code generation, in spirit of M$ ILX, but this is faaaaaar from
trivial.

-- 
: Michal Moskal ::::: malekith/at/pld-linux.org :  GCS {C,UL}++++$ a? !tv
: PLD Linux ::::::: Wroclaw University, CS Dept :  {E-,w}-- {b++,e}>+++ h
-------------------
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 21:13 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 [this message]
2002-11-30 23:06           ` Mike Lin
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=20021130102400.GA2705@roke.freak \
    --to=malekith@pld-linux.org \
    --cc=caml-list@inria.fr \
    --cc=mikelin@MIT.EDU \
    /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).