Hacker News Reader

Comment by k_bx | Hacker News Reader

That's a good question! Some things are hard to predict (compile times), some are easier (their abuse would grow, very soon Elm would loose the first "newbie friendliness" point).

View on HN

Yeah, I think typeclass by themselves are not harmful, but then common libraries will be full of them, providing nice error messages would be harder, and then you might attract too much of the category theory folks declaring functors everywhere and scaring the newbies. (Nothing against category theory, but it's not really newbie friendly which is what Elm tries to be)

Interestingly enough, I think that Category Theory is more of a saviour here than anything, reason being this: most of the harm from over-using type classes comes from the cases when their usage can be avoided, and a general rule of thumb in the Haskell world is now this: if there are no laws that your type-class is bringing, avoid using it. Thus, Functor is ok, but "HasStatsField" stuff is not really.

HasField typeclass was recently added to GHC. It has no laws.

https://github.com/ghc-proposals/ghc-proposals/blob/master/p...

Luckily, all that stuff will be outdated with somewhat proper records https://github.com/ghc-proposals/ghc-proposals/pull/282

The RecordDotSyntax extension is just syntactic sugar for the HasField typeclass. It doesn't make HasField "outdated". Anyway, the HasField typeclass (with the proposed change to support field updates[1]) does have at least one law:

    uncurry ($) (hasField @x r) == r

or expressed with the getField and setField wrappers:

    setField @x r (getField @x r) == r

[1] https://github.com/ghc-proposals/ghc-proposals/blob/master/p...

Reply on news.ycombinator.com