I swear there used to be a T-shirt for sale featuring the immortal words:
What part of
do you not understand?
In my case, the answer would be... all of it!
In particular, I often see notation like this in Haskell papers, but I have no clue what any of it means. I have no idea what branch of mathematics it's supposed to be.
I recognise the letters of the Greek alphabet of course, and symbols such as "∉" (which usually means that something is not an element of a set).
On the other hand, I've never seen "⊢" before (Wikipedia claims it might mean "partition"). I'm also unfamiliar with the use of the vinculum here. (Usually it denotes a fraction, but that does not appear to be the case here.)
If somebody could at least tell me where to start looking to comprehend what this sea of symbols means, that would be helpful.
This syntax, while it may look complicated, is actually fairly simple. The basic idea comes from formal logic: the whole expression is an implication with the top half being the assumptions and the bottom half being the result. That is, if you know that the top expressions are true, you can conclude that the bottom expressions are true as well.
Symbols
Another thing to keep in mind is that some letters have traditional meanings; particularly, Γ represents the "context" you're in—that is, what the types of other things you've seen are. So something like
Γ ⊢ ...
means "the expression...
when you know the types of every expression inΓ
.The
⊢
symbol essentially means that you can prove something. SoΓ ⊢ ...
is a statement saying "I can prove...
in a contextΓ
. These statements are also called type judgements.Another thing to keep in mind: in math, just like ML and Scala,
x : σ
means thatx
has typeσ
. You can read it just like Haskell'sx :: σ
.What each rule means
So, knowing this, the first expression becomes easy to understand: if we know that
x : σ ∈ Γ
(that is,x
has some typeσ
in some contextΓ
), then we know thatΓ ⊢ x : σ
(that is, inΓ
,x
has typeσ
). So really, this isn't telling you anything super-interesting; it just tells you how to use your context.The other rules are also simple. For example, take
[App]
. This rule has two conditions:e₀
is a function from some typeτ
to some typeτ'
ande₁
is a value of typeτ
. Now you know what type you will get by applyinge₀
toe₁
! Hopefully this isn't a surprise :).The next rule has some more new syntax. Particularly,
Γ, x : τ
just means the context made up ofΓ
and the judgementx : τ
. So, if we know that the variablex
has a type ofτ
and the expressione
has a typeτ'
, we also know the type of a function that takesx
and returnse
. This just tells us what to do if we've figured out what type a function takes and what type it returns, so it shouldn't be surprising either.The next one just tells you how to handle
let
statements. If you know that some expressione₁
has a typeτ
as long asx
has a typeσ
, then alet
expression which locally bindsx
to a value of typeσ
will makee₁
have a typeτ
. Really, this just tells you that a let statement essentially lets you expand the context with a new binding—which is exactly whatlet
does!The
[Inst]
rule deals with sub-typing. It says that if you have a value of typeσ'
and it is a sub-type ofσ
(⊑
represents a partial ordering relation) then that expression is also of typeσ
.The final rule deals with generalizing types. A quick aside: a free variable is a variable that is not introduced by a let-statement or lambda inside some expression; this expression now depends on the value of the free variable from its context.The rule is saying that if there is some variable
α
which is not "free" in anything in your context, then it is safe to say that any expression whose type you knowe : σ
will have that type for any value ofα
.How to use the rules
So, now that you understand the symbols, what do you do with these rules? Well, you can use these rules to figure out the type of various values. To do this, look at your expression (say
f x y
) and find a rule that has a conclusion (the bottom part) that matches your statement. Let's call the thing you're trying to find your "goal". In this case, you would look at the rule that ends ine₀ e₁
. When you've found this, you now have to find rules proving everything above the line of this rule. These things generally correspond to the types of sub-expressions, so you're essentially recursing on parts of the expression. You just do this until you finish your proof tree, which gives you a proof of the type of your expression.So all these rules do is specify exactly—and in the usual mathematically pedantic detail :P—how to figure out the types of expressions.
Now, this should sound familiar if you've ever used Prolog—you're essentially computing the proof tree like a human Prolog interpreter. There is a reason Prolog is called "logic programming"! This is also important as the first way I was introduced to the H-M inference algorithm was by implementing it in Prolog. This is actually surprisingly simple and makes what's going on clear. You should certainly try it.
Note: I probably made some mistakes in this explanation and would love it if somebody would point them out. I'll actually be covering this in class in a couple of weeks, so I'll be more confident then :P.
:
means has type∈
means is in. (Likewise∉
means "is not in".)Γ
is usually used to refer to an environment or context; in this case it can be thought of as a set of type annotations, pairing an identifier with its type. Thereforex : σ ∈ Γ
means that the environmentΓ
includes the fact thatx
has typeσ
.⊢
can be read as proves or determines.Γ ⊢ x : σ
means that the environmentΓ
determines thatx
has typeσ
.,
is a way of including specific additional assumptions into an environmentΓ
.Therefore,
Γ, x : τ ⊢ e : τ'
means that environmentΓ
, with the additional, overriding assumption thatx
has typeτ
, proves thate
has typeτ'
.As requested: operator precedence, from highest to lowest:
λ x . e
,∀ α . σ
, andτ → τ'
,let x = e0 in e1
, and whitespace for function application.:
∈
and∉
,
(left-associative)⊢
How do I understand the Hindley-Milner rules?
Hindley-Milner is a set of rules in the form of sequent calculus (not natural deduction) that says you can deduce the (most general) type of a program from the construction of the program without explicit type declarations.
The symbols and notation
First, let's explain the symbols
See "Practical Foundations of Programming Languages.", chapters 2 and 3, on the style of logic through judgements and derivations. The entire book is now available on Amazon.
Chapter 2
Inductive Definitions
Inductive definitions are an indispensable tool in the study of programming languages. In this chapter we will develop the basic framework of inductive definitions, and give some examples of their use. An inductive definition consists of a set of rules for deriving judgments, or assertions, of a variety of forms. Judgments are statements about one or more syntactic objects of a specified sort. The rules specify necessary and sufficient conditions for the validity of a judgment, and hence fully determine its meaning.
2.1 Judgments
We start with the notion of a judgment, or assertion about a syntactic object. We shall make use of many forms of judgment, including examples such as these:
A judgment states that one or more syntactic objects have a property or stand in some relation to one another. The property or relation itself is called a judgment form, and the judgment that an object or objects have that property or stand in that relation is said to be an instance of that judgment form. A judgment form is also called a predicate, and the objects constituting an instance are its subjects. We write a J for the judgment asserting that J holds of a. When it is not important to stress the subject of the judgment, (text cuts off here)
The notation comes from natural deduction.
⊢ symbol is called turnstile.
The 6 rules are very easy.
Var
rule is rather trivial rule - it says that if type for identifier is already present in your type environment, then to infer the type you just take it from the environment as is.App
rule says that if you have two identifierse0
ande1
and can infer their types, then you can infer the type of applicatione0 e1
. The rule reads like this if you know thate0 :: t0 -> t1
ande1 :: t0
(the same t0!), then application is well-typed and the type ist1
.Abs
andLet
are rules to infer types for lambda-abstraction and let-in.Inst
rule says that you can substitute a type with less general one.There are two ways to think of e : σ. One is "the expression e has type σ", another is "the ordered pair of the expression e and the type σ".
View Γ as the knowledge about the types of expressions, implemented as a set of pairs of expression and type, e : σ.
The turnstile ⊢ means that from the knowledge on the left, we can deduce what's on the right.
The first rule [Var] can thus be read:
If our knowledge Γ contains the pair e : σ, then we can deduce from Γ that e has type σ.
The second rule [App] can be read:
If we from Γ can deduce that e_0 has the type τ → τ', and we from Γ can deduce that e_1 has the type τ, then we from Γ can deduce that e_0 e_1 has the type τ'.
It's common to write Γ, e : σ instead of Γ ∪ {e : σ}.
The third rule [Abs] can thus be read:
If we from Γ extended with x : τ can deduce that e has type τ', then we from Γ can deduce that λx.e has the type τ → τ'.
The fourth rule [Let] is left as an exercise. :-)
The fifth rule [Inst] can be read:
If we from Γ can deduce that e has type σ', and σ' is a subtype of σ, then we from Γ can deduce that e has type σ.
The sixth and last rule [Gen] can be read:
If we from Γ can deduce that e has type σ, and α is not a free type variable in any of the types in Γ, then we from Γ can deduce that e has type ∀α σ.