Thoughts on using Structs of Functions as typeclasses?

[AZMCode]

While I appreciate the addition of implicit parameters, I have often found myself having to use copious amounts of them to do useful stuff with them. For example in type-generic arithmetic, where I'll often need to declare the various arithmetic operations, plus some constants for one and zero and the like, plus comparisons, plus bit-shifting operations if I require them. All of these things would often be packaged in a typeclass like "Integral" or "EuclideanRing", for example.

I understand some languages that don't have full typeclass support (and in the case of Koka, if I understand correctly, don't plan on implementing it) mimick typeclasses using structs of functions, and I wondered if these two mechanisms, structs of functions and implicit parameters, fused together, could yield idiomatic code, or perhaps are an antipattern.

[TimWhiting]

https://github.com/koka-lang/koka/blob/dev/test/overload/monoid2.kk

There are a few samples in the test folder that show how you can automatically unwrap functions & values in a struct using implicits by prefixing the ? with a . exactly for this kind of use case.

[AZMCode]

That is fascinating. Thanks for the input!

If this is an intended pattern, I wonder, will the standard library include instances of this pattern eventually?

That is speculation on my part though. Hope to see the documentation on implicits and other goodies eventually make its way into the koka book.

One last question. Is it also intended that operators cannot be stored in structs then?
I mean, the functions they represent can, but I haven't found a way to include an operator in a struct with its original name.

[TimWhiting]

I can't say for certain, but I do think we will see instances of the pattern in the standard library eventually. However, it is a delicate balance between providing very general abstract methods, and providing specific overridden instances. It is better to use the specific instances to guarantee better performance and avoid increase in binary size for example. With optimizations I would hope that we can inline / specialize and otherwise optimize much of the implicits, but it isn't clear exactly how much we can rely on such optimizations.

Why don't you create an issue for the operators being stored in structs. Include the typeclasses use case as a motivating example.

[AZMCode]

Done