Write You a Haskell Stephen Diehl

Type Error Provenance
Before our type inference engine would generate somewhat typical type inference error messages. If two
terms couldn’t be unified it simply told us this and some information about the toplevel declaration
where it occurred. Leaving us with a bit of a riddle about this error came to be.
Cannot unify types:
Int
with
Bool
in the definition of ’foo’
Effective error reporting in the presence of type inference is a difficult task, effectively our typechecker
takes our frontend AST and transforms it into a large constraint problem but effectively destroys position
information information in the process. Even if the position information were tracked, the nature of
unification is that a cascade of several unifications can give rise to invalid solution and the immediate
two syntactic constructs that gave rise to a unification fail are not necessarily the two that map back
to human intuition about how the type error arose. Very little research has done on this topic and it
remains a open topic with very immediate and applicable results to programming.
To do simple provenance tracking we will use a technique of track the “flow” of type information through
out typechecker and associate position information associated with the inferred types back to their position
information in the source.
type Name = String
data Expr
= Var Loc Name
| App Loc Expr Expr
| Lam Loc Name Expr
| Lit Loc Int
data Loc = NoLoc | Located Int
deriving (Show, Eq, Ord)
So now inside of our parser we simply attach Parsec information on to each AST node. For example for
the variable term.
variable :: Parser Expr
variable = do
x