5 ms·

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 y

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)

k_bx 7y ago
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.
- papln 7y ago
  HasField typeclass was recently added to GHC. It has no laws. https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0023-overloaded-record-fields.rst https://github.com/ghc-proposals/ghc-proposals/blob/master/p...
  - k_bx 7y ago
    Luckily, all that stuff will be outdated with somewhat proper records https://github.com/ghc-proposals/ghc-proposals/pull/282 https://github.com/ghc-proposals/ghc-proposals/pull/282
    - nybble41 7y ago
      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/proposals/0158-record-set-field.rst https://github.com/ghc-proposals/ghc-proposals/blob/master/p...