Browse thread
Typeclasses in OCaml (Was: Haskell vs OCaml)
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| 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. 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 >