CategoricalData
Investigate equality and comparison primitives without type classes
Currently, Hydra does not support type classes, and it only "fakes" type class inference in the Haskell coder to the extent that it will satisfy GHC. However, it is possibly a little over-cautious with respect to avoiding type classes. For example, there are 17 individual equalXxx functions (e.g. equalInt32, equalString, etc.) primitives in hydra.lib.equality, even though it has been demonstrated that only hydra.lib.equality.equal is actually needed in Haskell. Hydra's type inference has no trouble with the polymorphism of equal, and the type class annotation Eq a => is only needed once, where the primitive is implemented. The caveat is that it is possible to write Hydra programs (e.g. Equality.equal (lambda "x" $ var "x") (lambda "y" $ var "y")) which will not compile when mapped to Haskell.
Comparison and arithmetic functions can probably be simplified in a similar way, again with the caveat that without type class inference, the developer is free to write meaningless programs like Math.add (lambda "x" $ var "x") (lambda "y" $ var "y") which will only fail when you map them into concrete languages, or try to evaluate them using the interpreter. The lack of guardrails is probably better, at this point, than lots of distracting, redundant primitives.
Note: the reason equal and compare usually work well in Haskell is that we usually generate deriving (Eq, Ord) in the type definitions. That is to say, we are essentially doing limited type class inference already. We could integrate this logic into hydra.inference for actual type class inference which would reject hydra.lib.equality primitives in the case of non-comparable types.
The math primitives are different. We are not deriving Num or Integral, so these primitives are still limited to one primitive per numeric type for now. However, inference for these classes ought to be even simpler than it is for equality and comparison. The rule is simply: integer and float literal types get Num, while only integer literal types get Integral, assuming we carry those classes from Haskell into Hydra.
I am sure. It is just a question of when to do it. 32-bit integer arithmetic is the only kind which is currently used by the kernel or coders, so adding numeric/integral/real type classes isn't urgent, but it might be good to have this prior to the 1.0 release.