I must formalize a slice of Dependent Haskell in order to describe an elaboration procedure over it. The subset of Haskell I will consider is presented in Figure 6.1 on the next page. Note that all Haskell constructs are typeset in upright Latin letters; this is to distinguish these from Pico constructs, typeset in italics and often using Greek letters.
The version of Dependent Haskell presented here differs in a few details from the language presented in Chapter 4. These differences are to enable an easier specification
79UnlessF is known to be injective [86].
80Note that my development does not natively support functional extensionality, so that these
t,k ::= a|λqvar.t|Λqvar.t|t1t2|t1@t2|t :: s type/kind
| casetofalt|t1 →t2|t1 0→t2|fixt
| letx := t1int2
qvar ::= aqvar|@aqvar quantified variable
aqvar ::= a|a :: s quantified variable (w/o vis.)
alt ::= p→t case alternative
p ::= H x|_ pattern
s ::= quant qvar.s|t⇒s|t type scheme/polytype
quant ::= ∀ |0∀ |Π|0Π quantifier
decl ::= x :: s := t|x := t declaration
prog ::= ∅|decl; prog program
Figure 6.1: Formalized subset of Dependent Haskell
of the elaboration algorithm. Translating between the “real” Dependent Haskell of Chapter 4 and this version can be done by a preprocessing step. Critically, (but with one exception) no part of this preprocessor needs type information. For example,
∀a b. ... is translated to ∀@a.∀@b. ...so that it is easier to consider individual bound variables.
The exception to the irrelevance of type information is in dealing with pattern matches. Haskell pattern matches can be nested, support guards, perhaps view patterns, perhaps pattern synonyms [76], etc. However, translating such a rich pattern syntax into a simple one is a well studied problem with widely used solutions [2, 101] and I thus consider the algorithm as part of the preprocessor and do not consider this further.
6.2.1
Dependent Haskell modalities
Let’s now review some of the more unusual annotations in Dependent Haskell, originally presented in Chapter 4. Each labeled paragraph below describes an orthogonal feature (visibility, matchability, relevance).
The @ prefix Dependent Haskell uses an @ prefix to denote an argument that would normally be invisible. It is used in two places in the grammar:
• An @-sign before an argument indicates that the argument is allowed to be omitted, yet the user has written it explicitly. This follows the treatment in my prior work on invisible arguments [33].
• An@-sign before a quantified variable (in the definition for qvar) indicates that the actual argument may be omitted when calling a function. In a λ-expression,
this would indicate a pattern that matches against an invisible argument (Section 4.2.3.1). In a Π- or ∀-expression, the @-sign is produced by the preprocessor when it encounters a ∀... . orΠ... . quantification.
Ticked quantifiers Three of the quantifiers that can be written in Dependent Haskell come in two varieties: ticked and unticked. A ticked quantifier introduces matchable (that is, generative and injective) functions, whereas the unticked quantifier describes an unrestricted function space. Recall that type constructors and data constructors are typed by matchable functions, whereas ordinary λ-expressions are not.
Relevance The difference between ∀ andΠin Dependent Haskell is that the former defines an irrelevant abstraction (fully erased during compilation) while the latter de- scribes a relevant abstraction (retained at runtime). In terms, an expression introduced byλ is a relevant abstraction; one introduced by Λ is an irrelevant one.
6.2.2
let
should not be generalized
Though the formalized Haskell grammar includeslet, I will take the advice of Vytiniotis et al. [98] that let should not be generalized. As discussed at some length in the work cited, local, generalized lets are somewhat rare and can easily be generalized by a type signature. For all the same reasons articulated in that work, generalizing let poses a problem for Bake. We thus live with an ungeneralized let construct.
6.2.3
Omissions from the Haskell grammar
There are two notable omissions from the grammar in Figure 6.1 on the preceding page.
Type constants The Haskell grammar contains no production for H, a type con- stant. This is chiefly because type constants must be saturated with respect to universals in Pico, whereas we do not need this restriction in Haskell. Accordingly, type constants are considered variables that expand to type constants that have been η-expanded to take their universal arguments in a curried fashion. For example, Just
in Haskell, which can appear fully unsaturated, becomes λa:IrrelType.Just{a} in Pico.
Recursive let Following the decision not to include a letrec construct in Pico (Section 5.1.2), the construct is omitted from the formalized subset of Haskell as well. Having a formal treatment of letrec would require a formalization of Haskell’s consideration of polymorphic recursion [41, 62, 67], whereby definitions with type signatures can participate in polymorphic recursion while other definitions cannot. In turn, this would require a construct where a polymorphic function is treated
Metavariables:
α, β unification type variable ι unification coercion variable Grammar extensions: τ ::= . . .|αψ type/kind γ ::= . . .|ιψ coercion ζ ::= α|ι unification variable Θ ::= ∅|Θ,∀z.τ /α|Θ,∀z.γ/ι zonker (Section 6.3.1) ξ ::= ∅|ξ, ζ 7→ψ generalizer (Section 6.5) u ::= α:ρ∀∆.κ|ι: ∀∆.φ unif. var. binding
Ω ::= ∅|Ω,u unification telescope
Ψ ::= ∅|Ψ, δ|Ψ,u typing context
I elide the∀ when the list of variables or telescope quantified over would be empty. Figure 6.2: Additions to the grammar to supportBake.
monomorphically in a certain scope and polymorphically beyond that scope.81 The problems faced here are not unique to (nor made particularly worse by) dependent types. I thus have chosen to exclude this construct for simplicity.
We have now reviewed the source language of Bake, and the previous chapter described its target language,Pico. I’ll now fill in the gap by introducing the additions to the grammar needed to describe the inference algorithm.