Re: [Caml-list] Typeclasses in OCaml (Was: Haskell vs OCaml)

["Till Varoquaux" <till.varoquaux@gmail.com>]

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.

Till
On Thu, Aug 14, 2008 at 5:04 PM, Jim Farrand <jim@farrand.net> wrote:
> 2008/8/14 Peng Zang <peng.zang@gmail.com>:
>
>>  (=) : '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:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>