3 ms·

> solved at compile time and lexically scoped so do not qualify for "magic". That seems like too limiting a definition of "magic" to me. > implicit parameters

> solved at compile time and lexically scoped so do not qualify for "magic". That seems like too limiting a definition of "magic" to me. > implicit parameters are in fact a generalization of type classes. Well, not exactly, as far as I can tell. Type classes (in Haskell at least) are significantly more ergonomic. Since they semantically describe the user's types, they allow you to perform their operations directly with the user's values. Implicit parameters have to be pulled out of the implicit environment and used explicitly themselves, as far as I can tell. It's true that the underlying mechanism is (roughly) the same, but the surface-level behavior is what really matters, and there they are very different.

bad_user 8y ago
> "That seems like too limiting a definition of "magic" to me" What is your definition of "magic" then? Things that are unfamiliar? Please don't mention "explicit vs implicit", because Scala's implicits are in fact explicit, plus we can always talk of assembly language and how it lacks any magic. > "Well, not exactly, as far as I can tell. Type classes (in Haskell at least) are significantly more ergonomic." Ergonomics has nothing to do with whether a concept is a generalization of another. > "Since they semantically describe the user's types, they allow you to perform their operations directly with the user's values. Implicit parameters have to be pulled out of the implicit environment and used explicitly themselves, as far as I can tell." Nope, both type clases and implicit parameters allow for describing functions that turn type names into values. That's all there is to it. Or in other words, both type classes and Scala's implicits are about return type polymorphism. The only actual differences are that: 1. type classes in Haskell are supposedly coherent, i.e. the compiler is supposed to force a single type class instance in the whole project, however GHC does in fact not do that so you can end up with multiple instances of the same type in the same project 2. Scala's implicits are more flexible in what they allow, for example it has priority rules in case of conflicts, which allow say those implicits to work in the presence of OOP subtyping, or to work with multiple type params for describing things that are difficult to describe via type classes (but not necessarily desirable, e.g. the CanBuildFrom pattern) 3. working with Haskell's type classes is nicer, because for hierarchies in Scala you end up dealing with OOP issues (i.e. in modelling Haskell's type class hierarchies, we ended up debating on inheritance vs composition), plus we do a lot of manual plumbing in libraries like Typelevel Cats But trust me when I say this, fundamentally they are the same ;-) You can also read Martin Odersky's paper about it: http://ropas.snu.ac.kr/%7Ebruno/papers/TypeClasses.pdf http://ropas.snu.ac.kr/%7Ebruno/papers/TypeClasses.pdf
- tome 8y ago
  > 1. type classes in Haskell are supposedly coherent, i.e. the compiler is supposed to force a single type class instance in the whole project, however GHC does in fact not do that so you can end up with multiple instances of the same type in the same project Can you give an example?
- couchand 8y ago
  I don't think you understand my point: the implementation doesn't matter, what matters is the user's mental model. The mental model of typeclasses is focused of a specific, clearly defined use.

bad_user 8y ago

> "That seems like too limiting a definition of "magic" to me" What is your definition of "magic" then? Things that are unfamiliar? Please don't mention "explicit vs implicit", because Scala's implicits are in fact explicit, plus we can always talk of assembly language and how it lacks any magic. > "Well, not exactly, as far as I can tell. Type classes (in Haskell at least) are significantly more ergonomic." Ergonomics has nothing to do with whether a concept is a generalization of another. > "Since they semantically describe the user's types, they allow you to perform their operations directly with the user's values. Implicit parameters have to be pulled out of the implicit environment and used explicitly themselves, as far as I can tell." Nope, both type clases and implicit parameters allow for describing functions that turn type names into values. That's all there is to it. Or in other words, both type classes and Scala's implicits are about return type polymorphism. The only actual differences are that: 1. type classes in Haskell are supposedly coherent, i.e. the compiler is supposed to force a single type class instance in the whole project, however GHC does in fact not do that so you can end up with multiple instances of the same type in the same project 2. Scala's implicits are more flexible in what they allow, for example it has priority rules in case of conflicts, which allow say those implicits to work in the presence of OOP subtyping, or to work with multiple type params for describing things that are difficult to describe via type classes (but not necessarily desirable, e.g. the CanBuildFrom pattern) 3. working with Haskell's type classes is nicer, because for hierarchies in Scala you end up dealing with OOP issues (i.e. in modelling Haskell's type class hierarchies, we ended up debating on inheritance vs composition), plus we do a lot of manual plumbing in libraries like Typelevel Cats But trust me when I say this, fundamentally they are the same ;-) You can also read Martin Odersky's paper about it: http://ropas.snu.ac.kr/%7Ebruno/papers/TypeClasses.pdf http://ropas.snu.ac.kr/%7Ebruno/papers/TypeClasses.pdf

tome 8y ago
> 1. type classes in Haskell are supposedly coherent, i.e. the compiler is supposed to force a single type class instance in the whole project, however GHC does in fact not do that so you can end up with multiple instances of the same type in the same project Can you give an example?
couchand 8y ago
I don't think you understand my point: the implementation doesn't matter, what matters is the user's mental model. The mental model of typeclasses is focused of a specific, clearly defined use.