From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <ober.14@osu.edu>
X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr
X-Spam-Level: 
X-Spam-Status: No, score=0.4 required=5.0 tests=AWL,DNS_FROM_RFC_ABUSE 
	autolearn=disabled version=3.1.3
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104])
	by yquem.inria.fr (Postfix) with ESMTP id 094D6BC6B
	for <caml-list@yquem.inria.fr>; Mon, 31 Dec 2007 15:03:03 +0100 (CET)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Aq4HACaFeEdDWxLC/2dsb2JhbACBV6Vr
X-IronPort-AV: E=Sophos;i="4.24,226,1196636400"; 
   d="scan'208";a="7343823"
Received: from ip67-91-18-194.z18-91-67.customer.algx.net (HELO server1.bertec.net) ([67.91.18.194])
  by mail3-smtp-sop.national.inria.fr with ESMTP; 31 Dec 2007 15:02:59 +0100
Received: from kuba.bertec.net (kuba.bertec.net [192.168.2.16])
	by server1.bertec.net (Postfix) with ESMTP id 393EECDFB7
	for <caml-list@yquem.inria.fr>; Mon, 31 Dec 2007 09:02:55 -0500 (EST)
From: Kuba Ober <ober.14@osu.edu>
To: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] "OCaml gives you only monomorphic methods in classes."
Date: Mon, 31 Dec 2007 09:02:54 -0500
User-Agent: KMail/1.9.6 (enterprise 0.20071123.740460)
References: <200712282337.23952.jon@ffconsultancy.com> <200712290027.26471.jon@ffconsultancy.com> <1A5E39DC-CCAE-48B2-AC06-C671143A6C50@mac.com>
In-Reply-To: <1A5E39DC-CCAE-48B2-AC06-C671143A6C50@mac.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200712310902.54525.ober.14@osu.edu>
X-Spam: no; 0.00; ocaml:01 overloading:01 inference:01 foo:01 foo:01 statically:01 compilation:01 mangling:01 cheers:01 syntactic:01 compile:01 naming:01 caml-list:01 functions:01 monomorphic:01 

> >> Jon, consider the case of Java or C++ method (and function)
> >> overloading. This form of static dispatch is quite distinct from
> >> virtual method dispatch, and is indeed at odds with type inference.
> >
> > I see. Still, the solution seems easy enough. Just treat the
> > overloaded types
> > as part of the function name:
> >  foo(int n)
> > becomes:
> >  foo_int n
> > When you come across:
> >  foo(a)
> > you look up the statically inferred type of "a" and just bail if it
> > fails to
> > match any of the overloads.

> Oh, were you proposing a language feature? In that case, consider:
> let bar x = foo x
> How to compile that?

Check for all foo_xxx, and expand to
let bar_int x = foo_int x
let bar_float x = foo_float x
and so on.

The only thing I'm worried about is the fact that for one type,
there doesn't necessarily need to be a foo_xxx function. This naming solution 
isn't overly clean, so maybe it'd be better to do it slightly differently.

What about having the function name implicitly reference the signature, and do 
pattern matching on that?

So let's say we'd have

let add x y = x + y
let add x y = x + int_of_float y
let add x y = x +. y

let add2 x y = (x + 1) + (y - 1)
let add2 x y = (x + 1) + (int_of_float y - 1)
let add2 x y = (x +. 1.) + (y -. 1.)

And now we do

let add (x : int) y = add2 x y

This would replace the first two add functions, but not the third.

Presumably, for this feature to be safe to add to the language, there should
be some syntactic sugar to conveniently enable it for a function. No clue how
that'd look.

This would be a very useful addition to the language, although I'm sure it 
could make compilation longer in some cases, as the type inferrer would have
more choices to work with.

The "good old" mangling of the signature into the symbol is something we'd 
better not have to do manually.

For now I'm working on a very basic C++-to-Ocaml "converter" (in the spirit of 
web2c, i.e. only to work on one codebase), and this is definitely one of the 
issues I'm facing, as the code pretty much uses the whole spectrum of C++ 
features.

Cheers, Kuba