u/chrisdonerin r/haskell • Recommends
0:00 / 0:00
HIW 2014: Lennart Augustsson: Better type-error messages
Malcolm Wallace
884 subscribers • 13 videos on Hallway
- Recommended by 2 people: 1 on Lobsters and 1 in engineering communities.
- Presented by Lennart Augustsson, Haskell compiler engineer
- An opinion. It argues one side of a question engineers disagree on.
Advanced. Deep dive for people who know the field.
2.5K views12 years ago2 recommendations
Programming languagesSystems programmingHaskellCompilers and interpreters
Lennart Augustsson presents a humorous and insightful proposal for improving type-error messages in Haskell compilers.
Haskell Implementor's Workshop @ ICFP 2014. Gothenburg, Sweden.Why it's here
2 people recommend thisWhat people say. Recommended as a funny yet insightful lightning talk on compiler error message design.
HIW 2014: Lennart Augustsson: Better type-error messages (very funny)
bitemyappon Lobsters • Recommends
HIW 2014: Lennart Augustsson: Better type-error messages
u/chrisdonerin r/haskell • Mentions
On “Toward Better GHC Syntax Errors”
…y unrelated to the *real problem* that's 20 error messages down below.
I think better messages/UX is probably the more productive approach that teaching people divination from unhelpful messages. Lennart Augustsson did some work on the custom Haskell compiler they use at work with a small tweak (but big improvement) on error provenance. See here: link to this video I expect there're a number of low-hanging fruit or re-thinking of messages to be had. Consider the benefits gained by typed holes, which list the types of related bindings. That's a thing GHC has never done. Why? Because nobody with the chops thought to do it. But it's there in typed holes now.…
u/chrisdonerin r/haskell • Mentions
On “Lambda World 2018 - Introduction to the Unison programming language”
> thanks to bidirectional type checking!
I'd probably call that thanks to Lennart Augustsson, see Better type error messages. I implemented his idea in a simple HM unifying type inference for a language for a client, and yielded error messages like this:
Couldn't unify type: Number
From: <interactive>:1:16:
... let x = [ 1.0 , True ...
^^^
With type: Bool
From: <interactive>:1:18:
... = 1.0 , True in ...
^^^^
It tells you exactly where types came from.
There's definitely loads of work that someone could do if they just sat down, like Unison's author, and said "let's make type errors very high quality". Elm's are pre…
u/sclvin r/haskell • Mentions
On “Elm 0.16: Compilers as Assistants”
…re research along those lines would be very welcome.
One place where good progress has been made is in type error localization: http://cs.nyu.edu/wies/publ/finding_minimum_type_error_sources.pdf
Location reporting itself can be improved pretty simply as well, if we manage to implement the type error provenience stuff as shown by lennart in 2014: link to this video…