Skip to content
0:00 / 0:00

#typeerrors#haskell#compilers

HIW 2014: Lennart Augustsson: Better type-error messages

Malcolm Wallace

884 subscribers • 13 videos on Hallway

YouTube
  • 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 this

What people say. Recommended as a funny yet insightful lightning talk on compiler error message design.

u/chrisdonerin r/haskell • Recommends

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…