3 ms·
Describing Canonicity as a problem that that needs 'hacks' to work around seems a little disingenuous.
by platz 12y ago
Describing Canonicity as a problem that that needs 'hacks' to work around seems a little disingenuous.
- eduardoejp 12y agoplatz >> Describing Canonicity as a problem that that needs 'hacks' to work around seems a little disingenuous. If by "canonicity" you mean having 1 canonical instance of a type-class per type and by "hack" you mean using records as structs/modules, then I think you're not really appreciating the coolness of Lux's approach. Not only is Lux's approach simpler (just use records vs having to implement a complete type-class subsystem), but it's based on ideas that have existed for years in the ML world. ML's signatures & structures are not canonical, and yet all you hear is the ML guys praising their system, without a drop of envy for type-classes. Also, by having everything be based on records instead of ML's system, I get extra benefits and the language becomes much simpler. Some folks in the Haskell community have already talked about the issues that I address with Lux's module system. http://www.haskellforall.com/2012/05/scrap-your-type-classes.html http://www.haskellforall.com/2012/05/scrap-your-type-classes... Plus, using macros & the type-data in the compiler state, I've already conceived how a macro could be made that does code-transformations that make it seem as if you had globally-scoped type classes, as in Haskell. However, I still prefer ML's approach.