u/edwardkmettin r/haskell • Recommends
Boston Haskell: Edward Kmett - Type Classes vs. the World
0:00 / 0:00
#typeclasses#haskell#coherence
Edward Kmett - Type Classes vs. the World
Boston Haskell
1.1K subscribers • 18 videos on Hallway
- Recommended by 7 people: 2 on Hacker News, 2 on Lobsters and 3 in engineering communities.
- A classic. People kept recommending it from 2015 to 2023.
- Presented by Edward Kmett
- An opinion. It argues one side of a question engineers disagree on.
Advanced. Deep dive for people who know the field.
35K views11 years ago7 recommendations
Programming languagesComputer scienceLanguage design and type systemsFunctional programming
Edward Kmett discusses the design tradeoffs of global coherence in type classes compared to other implicit instance approaches.
Boston Haskell Meetup - January 21, 2015Why it's here
7 people recommend thisWhat people say. Recommended as a fundamental explanation of why type class coherence and global uniqueness of instances matter for reasoning and refactoring.
Moments people linked to
u/haskellgr8in r/haskell • Recommends
Back in early 2015, someone asked E. Kmett a great question: Why can't I use version 0.1 of some package internally in my program - even if rest of the environment uses 2.0 of the package? Has anything been done in this area since? (I don't notice anything in Stack, for example.)
u/cledamyin r/ProgrammingLanguages • Recommends
Type Classes vs. the World: why type class coherence matters
shadytreeson Hacker News • Recommends
On “Haskell's Type Classes: We Can Do Better”
The point is a little more subtle than this, or how the article made it out to be. Global coherence and confluence (which GHC attempts to enforce unless told otherwise) is great for refactoring and equational reasoning and (yes) mathematics and programming at large, as Ed Kmett's fantastic "Typeclasses v. the World" talk covers: link to this video Global uniqueness of instances (which GHC does NOT enforce) is bad for modular programming, or programming at large, which is a point some of the commenters here are making. link The submitted HN link here has a terrible title. What the author is proposing is enforcing typeclass laws, which is a great idea (but difficult in practice to implement). Practice…
Tweyon Hacker News • Recommends
On “This isn’t the way to speed up Rust compile times”
Edward Kmett has a great explanation1 of the considerations around this space. It's not that alternatives to the orphan rule are hard to implement, it's that they lead to things being much harder to reason about for the programmer. 1: link to this video
u/edwardkmettin r/haskell • Mentions
On “Haskell's Typeclasses: We Can Do Better”
…full-on Haskell-style type-classes. Instead you get things like `coq` which blesses precisely one path through the class inheritance hierarchy, or mechanisms that are secretly like Scala's implicits, where provenance matters. In such dependently typed settings it also raises the concern of just in what notions of equality a given instance holds.
link to this video…
u/Iceland_jackin r/haskell • Mentions
On “What did you wish you had known about in the first two weeks of learning Haskell?”
…t for mutation/arrays.
* Do not dismiss simple things, it doesn't have to be complicated to be useful.
data Bool = False | True
data Maybe a = Nothing | Just a
data Either a b = Left a | Right b
data Ordering = LT | EQ | GT
(.. what Edward Kmett refers to as ‘dumb reusable data’ ^^[**YouTube**](link to this video
id :: a -> a
id x = x
const :: a -> b -> a
const x _ = x
* Write instances by hand, write them many times and make sure you understand the **un**intuitive ones. You know `fmap @[]` is the same as `map` (the `@` uses *type applications*) but `fmap @((->) _) = (.)` may surprise you. Same with (see link to this video if…
u/telin r/ocaml • Mentions
Edward Kmett's "Typeclasses versus the world", call for responses
Edward Kmett gave a talk recently entitled "Typeclasses versus the world" where he argued that the semantics of typeclasses make the kind of work he enjoys doing not only easy but even, perhaps, feasible.
There's a long battle between typeclasses and modules—their relative advantages, disadvantages, the difficulties of implementing both simultaneously. I think Ed's talk, while happily and self-consciously biased, was unduly informative due to his aim to defend typeclasses as something much more than just a convenience but instead as a very powerful system for having Haskell generate sensible, reasonable code for you. In pa…
u/Disjunction181in r/ProgrammingLanguages • Mentions
On “Talks by designers of popular languages?”
I'll just contribute a couple:
* Typeclasses vs. the World
* The Promise of Relational Programming
u/edwardkmettin r/haskell • Mentions
On “Data.Constraint - dict as paramaeter for function?”
This package isn't designed to allow named instances, which lead to things like the existing Data.Set being unsafe, because it relies on the instance you get in `insert` to be the same that you get later in `lookup`. See link to this video for more on why that would break a bunch of desirable properties that Haskell has today.
Haskell is (almost) unique among all of the different programming languages that purport to offer "type classes" (Rust is one such exception, apparently.) in that you can bank on the instance you get for a given type being the same no matter how you get it. This makes a lot of refactorings safe in Haskell that aren't safe in Scala, or even Coq, Agda, Idris..
What `constraints`…
u/raiphin r/ProgrammingLanguages • Mentions
On “Scrapping the typeclasses”
…th mathematical laws are okay". My reasoning is that laws let you reason abstractly about what the type class does without consulting the source code. So, for example, I'm okay with type classes like \`Monad\`, \`Functor\`, and \`Monoid\`, but not with type classes like \`IsWritable\` or \`HasFoo\`.
And:
>\> This seems to be slightly relevant: [video Edward Kmett talks about how Haskell type classes are different and (in his opinion) more powerful then the similar constructs in other languages. Specifically, the property that all diagrams commute ([video doesn't seem to hold for this solution. That said, I agree that your approach is powerful and that type classes are often used unnec…
u/dnkndntsin r/haskell • Mentions
On “Why type classes?”
Surprised noone's linked Type Classes vs. The World.
The main thing coherence buys you is not needing to know which modules were in scope to know which instance a function is talking about. Contrast this to some other languages (apparently Scala) which try to resolve which instance in scope is the Best One via a set of prioritization rules.
Personally, I'm okay with Agda's solution, which says instances don't have to be globally unique, but at any particular use site, the program will refuse to compile if the resolution does not turn out to be unique (where "unique" means all paths to a valid instance resulted in the same term up to definitional equality). This does mean that unlike (ide…
u/superstar64in r/ProgrammingLanguages • Mentions
On “Any idea how to solve the orphan instance problem?”
> Haskell's typeclasses have some limitations. The principle difficulty is that you can't have multiple implementations of a typeclass for a given type (you instead have to use newtypes, for example)
Edward kmett gave this(link to this video talk that explains how that is a good thing.
u/evohunzin r/haskell • Mentions
On “Why are we naming types instead of instances when we have multiple instances per type?”
~~Do you have a link to the talk?~~
Found it: link to this video