4 ms·
The OCaml code for the Person module in that post is not not idiomatic. Also, a module is quite different from a class or JS object and it would be more helpful
by lindig 11y ago
The OCaml code for the Person module in that post is not not idiomatic. Also, a module is quite different from a class or JS object and it would be more helpful to think about a module implementing an (abstract) data type like in C or other procedural languages. There is no inheritance with modules and no dynamic dispatch. Once compiled, there is no selection of functions/methods at runtime.
- anonymousDan 11y agoSo how does an ocaml module compare to a Haskell type class?
- int3 11y agoHaskell's typeclasses automatically do dictionary passing for you; OCaml modules require you to specify the dictionary yourself. See http://okmij.org/ftp/Computation/typeclass.html http://okmij.org/ftp/Computation/typeclass.html
- lindig 11y agoOCaml modules and Haskell type classes are quite separate, too. I would make more sense to compare OCaml and Haskell modules. Haskell type classes implement ad-hoc polymorphism and OCaml doesn't have that at all. You can't implement in OCaml something like a show function that works on integers and strings and list of integers and so on like in Haskell using the Show type class.
- DonPellegrino 11y agoYou sort of can with functors or GADTs.
- lindig 11y agoLike you say, sort of. This would imply that you wrap all the basic types in a sum type. It's quite heavy. Using the PPX mechanism the compiler can also be extended to generate this code automatically but again, this isn't very natural at the moment.
- namanbharadwaj 11y agoIn fact, OCaml modules do correspond to Haskell type class instances, and there are ways to extend the ML module system to support ad-hoc style polymorphism (http://www.mpi-sws.org/~dreyer/papers/mtc/main-long.pdf http://www.mpi-sws.org/~dreyer/papers/mtc/main-long.pdf). On the other hand, you can also use modules as a simple namespacing mechanism (as in Haskell modules). But this does not capture the full power of the module system.
- tel 11y agoModules can be seen as a collection of types (abstract or otherwise) and functions acting upon those types. Very prosaically, this can just be a type parameterized dictionary (or vtable if that floats your boat). Haskell's "constrained" types look like this c => a where the type `a` requires access to the details of a constraint `c`. It turns out that constraints are merely type parameterized dictionaries of functions acting upon those types. We could reify them into concrete data types if we liked and then replace the fat arrow (Dict of c) -> a and get something functionally equivalent. Now, instead of doing that Haskell has the typeclass mechanism which allows the compiler to automatically generate and pass needed constraints based on a prolog-like logic that executes at compile time. This can be convenient but restricts the flexibility of these dictionaries. ML modules can do some of the very same things but require the user to manually wire the proper module in at the right time instead of letting the compiler do it [0]. The benefit is that your modules are more modular and can support more sophistication. [0] Caveat: this compiler automatic dictionary wiring will be enabled, in part, with OCaml's modular implicits which are coming down the pike soon.