Sneak Peek: Bolt Math

I also have a pie-in-the-sky shopping list of algebraic classes. I think you have finessed yours in a lot of ways that I haven’t, but there might be things in there that you can borrow.

Some thoughts about your design:

• I would strongly encourage you to name the classes to match existing Haskell patterns, to minimise the disruption to existing practitioners, and to prevent newcomers from getting stuck in your own little custom universe. This heuristic leads me to suggest FromInteger over ExpressibleByIntegerLiteral, for example. I’d also be careful how you name the ConvertibleTo classes because unlike the ExpressibleBy/From classes, you don’t actually have a source file containing a literal that’s being parsed, and e.g. both Integer and Rational can generate values with arbitrarily large textual representations.
• I’d extend this heuristic to using the real mathematical names for things, which I think is fine if you give them really good haddocks and thorough motivations and examples. Package acts is a good example of this, but we can go even further. Although I wasn’t there when it was defined, I consider the historical weirdness of Num a result of not shopping from the algebraic catalogue.
• I can see why you’d want to put each arithmetic operation into its own class, but if you’re going to do that I’d consider putting the traditional operators in there.
• I have baked in the assumption that my operations are all closed, whereas you have chosen to define associated type families for the result types. I recommend checking whether type inference is still good enough in your design. Not being able to reason from the type of a result of basic algebraic operation back through to the argument types could force a lot of manual type signatures in intermediate lets in complex numeric code, ballooning contexts in your type signatures, or other syntactic noise.
• I think you’ve done a lot more thinking about where the miscellaneous numeric functions need to go, which I’ve glossed over in my post. Good.
• Both of our sketches have a real issue with law-only typeclasses. They’re dangerous for inference (your code infers a signature that doesn’t include a class whose law you rely on) and AFAIK nobody has a thorough solution yet.
• With these large class hierarchies, there’s also a real problem asking people to implement/derive the entire hierarchy for their types. Again, I don’t think anyone’s got a full answer yet, especially when one wants to add a new class to the middle of the hierarchy.
• You might need equivalents to stimes and mtimes which can do repeated squaring for efficiency.