4 ms·
You can't parametrize type classes over one another in the same way. In practice, this often makes ML style modules much more expressive: for example, I can hav
by nv-vn 10y ago
You can't parametrize type classes over one another in the same way. In practice, this often makes ML style modules much more expressive: for example, I can have a Hashable type class with one implementation per type that is used by a HashSet data type or module, but with MLs there could be a number of modules for the same type implementing the hash function, which can be used to construct the set. This also means things like Monoids or Semigroups greatly benefit, since now you can easily have more than just (+) for ints, for example. You can even use this to derive operations like folds from your base module where you'd never have to apply the arguments to a folder; instead you could do Sum.fold or Product.fold based on the different base modules.
- wyager 10y agoYou can do this in Haskell as well, it's just clunkier since you usually end up needing some combo of MultiParamTypeClasses and plumbing around extra types. The ML approach is better for this use case, but the Haskell approach can do the same with a bit more verbosity.
- nv-vn 10y agoOf course, but at that point one could throw in OCaml extensions (modular implicits + HKTs) to provide the Haskell functionality to OCaml.