From: Xavier Leroy <xleroy@pauillac.inria.fr>
Message-Id: <199601080940.KAA06302@pauillac.inria.fr>
Subject: Re: entiers et reels
To: ohl@crunch.ikp.physik.th-darmstadt.de (Thorsten Ohl)
Date: Mon, 8 Jan 1996 10:40:41 +0100 (MET)
In-Reply-To: <9601052114.AA03157@crunch> from "Thorsten Ohl" at Jan 5, 96 10:14:07 pm
> Maybe I'm too dense or I have been exposed to too much Fortran, but I
> don't fully understand:
> Standard ML has [overloaded arithmetic operators]
> (at least in the New Jersey incarnation), so why
> can't Caml?
Caml could very well have it. Indeed, the old Caml V3.1 implementation
has support for overloaded operators that far exceeds what NJML provides.
> As long as all operands are of the same type, the
> semantics should be obvious.
The semantics are obvious once types are assigned to all
subexpressions of the program. But that's where the problem lies in
a language with type inference. Consider:
let f x y = x + y
Assuming + works on ints and floats, f has two possible types, namely
int -> int -> int and float -> float -> float. These are the only two
types. In particular, their least upper bound 'a -> 'a -> 'a is not
a valid type for f (unless + is implemented with run-time type tests,
as in Michel Quercia's post, but this defeats the whole purpose of
static typing -- just go back to Scheme, then).
So, the type inferencer fails on the definition above ("cannot resolve
overloading"), and the programmer must add a type constraint:
let f (x:float) y = x + y
Frankly, if I must explain the compiler what I mean, I'd rather not
have + overloaded and write +. for float addition:
let f x y = x +. y
Of course, in larger examples, there's more context that helps in
resolving overloading, e.g.
let f x = x + y * 3.14
But the general problem remains: in the presence of overloaded
operators, ML's type system no longer possesses the principal typing
property, hence type inference can fail on well-typed but ambiguous
programs.
Lots of effort have been invested in trying to resolve that problem,
in particular the development of type classes as implemented in Haskell.
But it really opens a whole new can of worms, both on the semantic
side and on the implementation side.
If you're interested, here are some references:
Wadler and Blott, "How to make ad-hoc polymorphism less ad-hoc",
POPL 89.
Hudak et al, "Report on the programming language Haskell",
SIGPLAN Notices 27(5), 1992.
Dubois, Rouaix, and Weis, "Extensional polymorphism", POPL 95.
Harper and Morriset, "Compiling polymorphism using intensional
type analysis, POPL 95.
As you can see, the problem of overloaded operators is far from
solved. Until the dust settles, I'd rather keep Caml Light simple and
implement no overloading at all.
- Xavier Leroy