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
Typeclasses in OCaml (Was: Haskell vs OCaml)
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2008-08-14 (18:37)
From: Till Varoquaux <till.varoquaux@g...>
Subject: Re: [Caml-list] Typeclasses in OCaml (Was: Haskell vs OCaml)
Typw inference in haskell is not decideable (nor is it in ocaml when
using objects) and you have to provide some type information. I would
much rather trade some inference for more power in the type system
(value restriction and lack of higher rank polymorphic really kill
some coding styles....) but thta is a matter of taste. Didier Remy is
working on ML F which should address those.

On top of breaking inference type cleases come at a high run tine
cost. You can regain a lot by doing ad-hoc optimizations but this is
quite far from OCaml's philosophy: the compiler's optimisations (or
lack thereof) are very predictable which is nice once you move out of
toy programs.

On Thu, Aug 14, 2008 at 5:04 PM, Jim Farrand <> wrote:
> 2008/8/14 Peng Zang <>:
>>  (=) : 'a -> 'a -> bool
>> But instead:
>>  (=) : (#equatable as 'a) -> 'a -> bool
>> where
>>  class type equatable = object
>>    method equals : 'self -> bool
>>  end
>> This gives all the advantages of static typing and type inference and prevents
>> stupid errors and it is meaningful for all types that it is implemented for.
> This doesn't answer my question at all.  :)
>  Is there any theoretical reason they couldn't added?  The kind of
> answer I'm looking for is "There is no theoretical reason why not", or
> "This is impossible as it would cause typing in OCaml to become
> undecidable, due to interactions with other features of the OCaml type
> system which aren't present in Haskell."
> Though, to address your solution, I am of course aware of it, but it
> has what seem like big disadvantages:
> 1. Every value in OCaml would then have to be an object
> 2. Every comparison now requires a relatively expensive dynamic
> dispatch, when the correct function could be determined at runtime.
> 3. If I add a new operator that wasn't thought of by the language
> implementors, it can't be easily added to primitive values, without
> either subclassing all of them, or changing the definition in the
> standard library to add the new method.
> Regards,
> Jim
> _______________________________________________
> Caml-list mailing list. Subscription management:
> Archives:
> Beginner's list:
> Bug reports: