[Caml-list] RE: OCaml on CLR/JVM?

[Anton Moscal <msk@post.tepkom.ru>]

On Fri, 9 Feb 2001, Don Syme wrote:

> Java/.NET component building seriously right from the start I feel you're
> always just going to end up with a bit of a hack - an interesting, usable
> hack perhaps, but not a really _good_ language.
> 
> Probably the greatest recurring technical problem that I see in this kind of
> work is that of type inference, and the way both the Java and .NET models
> rely on both subtyping and overloading to help make APIs palatable.  Type
> inference just doesn't work well with either subtyping or oveloading.  This
> is a great, great shame, as it's obviously one of the main things ML has to
> offer to improve productivity.  

I think, subtyping probably isn't serious problem: O'Caml already have
subtyping relations (between objects and also between variant types). And
only problem arisen is necessity of the explicit type specification in
some constructions.

O'Caml haven't overloading, but probably overloading can be implemented
in the same way as subtyping: by requirement of the explicit type
specifications in case of ambiguities (SML have some builtin
overloaded operators and resolve emerging problems in this way).

I think, there is more serious problem:

O'Caml have structural subtyping relation between objects, whereas .NET
type system have subtyping relation based on explicitly declared 
inheritance:

----------------------
class point1 (x:int) = object method x = x end 
class point2 (x:float) (y:float) = object method x = x method y = y end

let get_x p = p#x 

let _ = Printf.printf "%d\n" (get_x (new point1 1)) 
let _ = Printf.printf "%g\n" (get_x (new point2 10.0 20.0))
----------------------

function get_x has type <x: 'a; ..> -> 'a and can works with the any
object, which have method "x". I see no ways to map this into .NET
framework except using reflection (which is overkill). 

Also, point2 is subtype of point1, but there isn't explicit
inheritance declaration here. Moreover point1 and point2 can be defined
in independent modules and don't know each other.

Anton
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr