As someone who is not deep into type theory or functional programming, can you please explain why you mean by “ergonomic overloading”?
My understanding is that ocaml mitigates the need for type classes through its more advanced module system. So far I have been enjoying the use of OCaml modules, so I’m curious what exactly I’m missing out on, if any.
You have to be explicit about which module you’re using at all times, even though 99% of the time only one could apply. When the type class resolution is unique, but complicated, there’s no mental overhead for the Haskell programmer but getting all the right modules is a lot of overhead for the OCaml programmer. It also lets us write functions that are polymorphic under a class constraint. In OCaml you have to explicitly take a module argument to do this. If you want to start composing such functions, it gets tedious extremely fast.
And then even once you’re using a module, you can’t overload a function name. See: + vs +.. Basically modules and type classes solve different problems. You can do some things with modules that you cannot ergonomically do with type classes, for example. create a bit-set representation of sets of integers, and a balanced search tree for sets of other types, and expose that interface uniformly from the same module functor. But Haskell has other ways to achieve that same functionality and more.
OCaml’s type system cannot replicate the things you can do with Haskell’s higher kinded types, type families, or data kinds at all (except for a fraction of Haskell’s GADTs).
As someone who is not deep into type theory or functional programming, can you please explain why you mean by “ergonomic overloading”?
My understanding is that ocaml mitigates the need for type classes through its more advanced module system. So far I have been enjoying the use of OCaml modules, so I’m curious what exactly I’m missing out on, if any.
Thanks for taking the time to talk with me btw!
You have to be explicit about which module you’re using at all times, even though 99% of the time only one could apply. When the type class resolution is unique, but complicated, there’s no mental overhead for the Haskell programmer but getting all the right modules is a lot of overhead for the OCaml programmer. It also lets us write functions that are polymorphic under a class constraint. In OCaml you have to explicitly take a module argument to do this. If you want to start composing such functions, it gets tedious extremely fast.
And then even once you’re using a module, you can’t overload a function name. See:
+vs+.. Basically modules and type classes solve different problems. You can do some things with modules that you cannot ergonomically do with type classes, for example. create a bit-set representation of sets of integers, and a balanced search tree for sets of other types, and expose that interface uniformly from the same module functor. But Haskell has other ways to achieve that same functionality and more.OCaml’s type system cannot replicate the things you can do with Haskell’s higher kinded types, type families, or data kinds at all (except for a fraction of Haskell’s GADTs).