Very interesting that you are mentioning looking into multi-parameter type
classes! I will think a bit about it.
And thanks for the libraries you suggested, will also need to take some
times to look into them
FWIW: I made an actual OOP-style code in C++ to demonstrate the difference
between compile-time and run-time polymorphism
https://github.com/hellwolf/haskell-examples/blob/master/2022-05-25-inclusio...
On Fri, May 27, 2022 at 12:32 AM Olaf Klinke
So my central questions for discussions are:
- Is inclusion polymorphism something we should use at all in Haskell? - These boiler plate code maybe better be generated using Haskell template instead, is there one already, or should there be one?
Maybe one of the authors of a sub-typing library can share a more informed opinion on this. My view as a mathematician: A type being a subtype of another is a relation between types. Relations between types is what multi-parameter type classes is about. Hence it seems that this is how subtypes in Haskell ought to be done. For example, in the attenuation and records-sop package, the latter of which is based on genercis-sop, which depends on Template Haskell. So without having used any of the mentioned packages, I believe your second question can be answered with "yes". Regarding the first question, we should probably ask ourselves how much type-safety we're sacrificing for the convenience we gain. The Num example you gave shows one possible danger: While a subtype relation may hold mathematically, the implementiation details may cause this relation to fail in reality. Example: All floating point numbers are rationals, aren't they? So there should be a subtype relation. But how to convert NaN, -infinity or -0 of type Double to a pair of Integers?
Olaf