platz >> 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.
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.
Comments
Describing Canonicity as a problem that that needs 'hacks' to work around seems a little disingenuous.
platz >> 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...
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.