Very well-written, and interesting. I learned a lot about how haskell type classes are implemented through this paper: http://web.cecs.pdx.edu/~mpj/pubs/pldi93.

Very well-written, and interesting. I learned a lot about how haskell type classes are implemented through this paper: http://web.cecs.pdx.edu/~mpj/pubs/pldi93.html http://web.cecs.pdx.edu/~mpj/pubs/pldi93.html I've been working on a language which attempts to put type classes into a dynamic language. The implementation is a little interesting, because as I've tinkered with it, I've discovered essentially two cases of overloaded functions: * Ones where you can choose which implementation to use based on argument type. Similar to interfaces in Java, Go, etc, and multiple-dispatch languages. Also (I think) Rust only allows traits of this kind, but that might not be correct. * Ones where you choose the implementation based on the return type. This is mostly (from what I can tell) unique to Haskell and similar languages. It's what lets you write `return :: a -> m a` and be able to write `foo = return 3` and have `foo` work in any monad. Both of these approaches have their advantages and use cases. Haskell's system is nice because it allows for both, but because of how things are implemented, there's no introspection, so for example, a list "objects that implement Show" isn't feasible, because there's no way to inspect an object at runtime to determine its type. Or this is my understanding anyway. In my language, I treat each case differently, and can generate appropriate generic functions by inferring from the declared type signature(s) in the type class which case they fall into. Subsequently, its possible to mimic both behaviors in a dynamic setting. The only limitation (which I might be able to avoid) is that using the second type requires an explicit cast; as in you can say `foo = pure 2; bar = foo : [Num]; baz = foo : Just Num`. Of course, introspection has a performance penalty as well. Just thought some might find this interesting :)