Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] Observations on OCaml vs. Haskell
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2004-09-29 (15:03)
From: Dmitry Lomov <dmitry.lomov@j...>
Subject: Re: [Caml-list] Observations on OCaml vs. Haskell
Brian Hurt wrote:
> On Tue, 28 Sep 2004, Jon Harrop wrote:
>>On Tuesday 28 September 2004 08:22, Ville-Pertti Keinonen wrote:
>>>I'm fairly certain that type safety is a significant part of the reason;
>>>if they were polymorphic, they'd accept any kind of arguments, not just
>>>numbers.  What's the product of two strings?  A run-time type error?
>>It seems odd then, that the polymorphic comparisons do raise run-time type 
>>errors (on functions). I guess that's just the way the cookie crumbled...
>>I think a static analysis program to pick up on such problems could be very 
> This gets tricky, I would think.  One thing I don't want to lose is the 
> ability to make ('a -> 'b) list types.  Comparing two functions is 
> obviously bogus, but in most other places being able to handle both 
> functions and data is a usefull thing.
Apparently one needs some sort of bounded quantification on polymorphic 
functions, bound being "'a can be anything but a function".

Interestingly, one already can have the quantification bounded other way 
round ("'a can be any function") - just write 'b -> 'c instead of 'a. 
This bounding corresponds, of course,  to partial order imposed by type 

Dmitry Lomov
JetBrains Inc.
"Develop With Pleasure!"

To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: