Associated Type Synonyms

13 Pages·2014·0.25 MB·English

Associated Type Synonyms
ManuelM.T.Chakravarty GabrieleKeller SimonPeytonJones
UniversityofNewSouthWales MicrosoftResearchLtd.
ProgrammingLanguagesandSystems Cambridge,UK
{chak,keller}@cse.unsw.edu.au [email protected]
Abstract classCollectscwhere
typeElemc --Associatedtypesynonym
Haskell programmers often use a multi-parameter type class in
empty :: c
whichoneormoretypeparametersarefunctionallydependenton
insert :: Elemc → c → c
thefirst.Althoughsuchfunctionaldependencieshaveprovedquite
toList :: c → [Elemc]
popularinpractice,theyexpresstheprogrammer’sintentsomewhat
indirectly. Developing earlier work on associated data types, we The type definition says that c has an associated type Elemc,
proposetoaddfunctionally-dependenttypesastypesynonymsto without saying what that type is. This associated type may then
type-class bodies. These associated type synonyms constitute an be used freely in the types of the class methods. An instance
interestingnewalternativetoexplicitfunctionaldependencies. declarationgivesanimplementationforElem,justasitgivesan
implementationforeachmethod.Forexample:
Categories and Subject Descriptors D.3.3 [Programming Lan-
guages]:LanguageConstructsandFeatures instanceEqe ⇒ Collects[e]where
{typeElem[e] = e; ...}
GeneralTerms Design,Languages,Theory instanceCollectsBitSetwhere
{typeElemBitSet = Char; ...}
Keywords Typeclasses;Typefunctions;Associatedtypes;Type
instance(Collectsc, Hashable(Elemc))
inference;Genericprogramming
⇒ Collects(ArrayIntc)where
{typeElem(ArrayIntc) = Elemc; ...}
1. Introduction
Haskellaficionadoswillrecognisethatassociatedtypesynonyms
Supposeyouwanttodefineafamilyofcontainers,wheretherepre- attackexactlythesameproblemasfunctionaldependencies,intro-
sentationtypeofthecontainerdefines(orconstrains)thetypeofits duced to Haskell by Mark Jones five years ago [15], and widely
elements.Forexample,supposewewantcontainerssupportingat usedsincetheninsurprisinglyvariedways,manyinvolvingtype-
leastinsertion,union,andamembershiptest.Thenalistcancon- levelcomputation.Wediscusstherelativestrengthsofthetwoap-
tainelementsofanytypesupportingequality;abalancedtreecan proachesindetailinSection6.Itistooearlytosaywhichis“bet-
only contain elements that have an ordering; and a bit-set might ter”;ourgoalhereisonlytodescribeandcharacteriseanewpoint
representacollectionofcharacters.Hereisarathernaturaltypefor inthedesignspaceoftypeclasses.
theinsertionfunctionoversuchcollections: Specifically,ourcontributionsarethese:
insert :: Collectsc ⇒ Elemc → c → c
• Weexploretheutilityandsemanticsoftypesynonymdeclara-
ThetypeclassCollectssaysthatinsertisoverloaded:itwillwork
tionsintypeclasses(Section2).
on a variety of collection types c, namely those types for which
the programmer writes an instance declaration for Collects. But • Wediscussthesyntacticconstraintsnecessarytokeeptypein-
whatisElem?TheintentisobviouslythatElemc istheelement ferenceinthepresenceofassociatedtypesynonymsdecidable
type for collection type c; you can think of Elem as a type- (Section3).
level function that transforms the collection type to the element • Wegiveatypesystemthatsupportsassociatedtypesynonyms
type.However,justasinsertisnon-parametric(itsimplementation and allows an evidence translation to an explicitly typed core
variesdependingonc),soisElem.Forexample,Elem[e]ise,but languageinthestyleofSystemF(Section4).
ElemBitSet isChar. • Wepresentatypeinferencealgorithmthatcanhandlethenon-
ThecoreideaofthispaperistoextendtraditionalHaskelltype syntacticequalitiesarisingfromassociatedtypesynonyms;the
classeswiththeabilitytodefineassociatedtypesynonyms.Inour algorithmconservativelyextendsJones’algorithmforqualified
example,wemightdefineCollectslikethis: types[12](Section5).
Thispaperisanaturaldevelopmentof,andiscomplementaryto,
ourearlier workon associateddatatypes [1],inwhich we allow
aclassdeclarationtodefinenewalgebraicdatatypes.Wediscuss
Permissiontomakedigitalorhardcopiesofallorpartofthisworkforpersonalor otherrelatedtypesystems—inparticular,functionaldependencies,
classroomuseisgrantedwithoutfeeprovidedthatcopiesarenotmadeordistributed HM(X),andMLmodules—indetailinSections6and7.Wede-
forprofitorcommercialadvantageandthatcopiesbearthisnoticeandthefullcitation velopedaprototypeimplementationofthetypechecker,whichwe
onthefirstpage.Tocopyotherwise,torepublish,topostonserversortoredistribute makeavailableonline.1
tolists,requirespriorspecificpermissionand/orafee.
ICFP’05 September26–28,2005,Tallinn,Estonia.
Copyright(cid:13)c 2005ACM1-59593-064-7/05/0009...$5.00.
1http://www.cse.unsw.edu.au/∼chak/papers/CKP05.html
2. ApplicationsofAssociatedTypeSynonyms languageswhenusedforthisstyleofprogramming.Intheircom-
parisonHaskell,includingmulti-parametertypeclassesandfunc-
We begin informally, by giving several examples that motivate
tionaldependencies,wasratedveryfavourably,exceptforitslack
associatedtypesynonyms,andshowwhatcanbedonewiththem.
ofsupportforassociatedtypes.
2.1 Formatting:typefunctionscomputefunctiontypes Hereispartoftheinterfacetoagraphlibrary,inspiredbytheir
paper;although,wehavesimplifieditconsiderably:
The implementation of a string formatting function whose type
typeEdgeg = (Nodeg, Nodeg)
depends ona formatspecifierseems anaturalapplication forde-
--Wesimplifybyfixingtheedgerepresentation
pendent types and meta programming [26]. Although Danvy [4]
classGraphgwhere
demonstratedthatStandardML’stypesystemispowerfulenough
typeNodeg
to solve this problem, type functions enable a more direct solu-
outEdges :: Nodeg → g → [Edgeg]
tion[10],usinganinductivedefinitioninsteadofexplicitcontinu-
ationpassingstyle.Thefollowingimplementationwithassociated classGraphg ⇒ BiGraphgwhere
synonymsisbasedon[22].Formatspecifiersarerealisedassingle- inEdges :: Nodeg → g → [Edgeg]
tontypes:2 Usinganassociatedtypesynonym,wecanmakethetypeofnodes,
dataI f = I f --Integervalue Nodeg,afunctionofthegraphtypeg.Basicgraphsonlysupport
dataC f = C f --Charactervalue traversalsalongoutgoingedges,whereasbi-graphsalsosupportgo-
dataS f = S Stringf --Literalstring ingbackwardsbyfollowingincomingedges.Agraphrepresenta-
tionbasedonadjacencylistswouldonlyimplementthebasicinter-
face,whereasonebasedonanadjacencymatrixcaneasilysupport
formatSpec :: S (I (S (C String)))
thebi-graphinterface,asthefollowinginstancesillustrate:
formatSpec = S "Int: "$I $S ", Char: "$C $"."
dataAdjListv = AdjList[[v]]
--Exampleformat:"Int: %d, Char: %c."
instanceEnumv ⇒ Graph(AdjListv)where
The singleton type declarations reflect the structure of a format
typeNode(AdjListv) = v
specifier value in their type. Consequently, we can use a speci-
outEdgesv g = [(v, w)|w ← g!!fromEnumv]
fier’stypetocalculateanappropriatetypeforasprintf function
typeAdjMat = Array.Array(Int, Int)Bool
appliedtothatspecifier.Weimplementthistypelevelcalculation
instanceGraphAdjMatwhere
bydefininganassociatedsynonymSprintf inaclassFormat in
typeNodeAdjMat = Int
thefollowingway:
outEdgesv g = let((from, ), (to, )) = boundsg
classFormatfmtwhere
in[w |w ← [from..to], g!(v, w)]
typeSprintf fmt
sprintf′ :: String → fmt → Sprintf fmt instanceBiGraphAdjMatwhere
inEdgesv g = let((from, ), (to, )) = boundsg
instanceFormatStringwhere
in[w |w ← [from..to], g!(w, v)]
typeSprintf String = String
sprintf′prefix str = prefix ++ str By making Edge, as well as Node, an associated type synonym
ofGraphandbyparameterisingovertraversalsandthedatastruc-
instanceFormata ⇒ Format(I a)where
turesusedtomaintainstateduringtraversals,theaboveclasscan
typeSprintf (I a) = Int → Sprintf a
sprintf′prefix (I a)= λi.sprintf′(prefix ++ show i)a bemadeevenmoreflexible,muchastheBoostGraphLibrary,or
instanceFormata ⇒ Format(C a)where theskeletonusedasarunningexamplebyGarciaetal.[8].
typeSprintf (C a) = Char → Sprintf a
sprintf′prefix (C a)= λc.sprintf′(prefix ++ [c])a
instanceFormata ⇒ Sprintf (S a)where
3. Theprogrammer’s-eyeview
typeSprintf (S a) = Sprintf a
sprintf′prefix (S str a)= sprintf′(prefix ++ str)a Inthissection,wegiveaprogrammer’s-eyeviewoftheproposed
languageextension.Formaldetailsfollowlater,inSection4.
sprintf :: Formatfmt ⇒ fmt → Sprintf fmt
sprintf = sprintf′"" Weproposethatatypeclassmaydeclare,inadditiontoasetof
methods,asetofassociatedtypesynonyms.Thedeclarationhead
Newformat-specifiertypes(suchasI andS above)canbeintro-
alone is sufficient, but optionally a default definition—much like
ducedbytheprogrammeratanytime,simplybydefiningthetype,
those for methods—may be provided. If no default definition is
andgivingamatchinginstancedeclaration;thatis,thedefinitionof
given,anoptionalkindsignaturemaybeused;otherwise,theresult
sprintf isopen,orextensible.
kindofasynonymapplicationisassumedtobe⋆.Anassociated
Noticehowimportantitisthattheassociatedtypeisasynonym:
typesynonymmustbeparametrisedoverallthetypevariablesof
itisessentialthatSprintf fmt isafunctiontype,notadatatype.
the class, and these type variables must come first, and be in the
sameorderastheclasstypevariables.
2.2 Genericdatastructures
Eachassociatedtypesynonymintroducesanewtop-leveltype
The collections abstraction Collects from Section 1 is an exam- constructor.Thekindofthetypeconstructorisinferredasusualin
pleofagenericdatastructure—othersincludesequences,graphs, Haskell;wealsoallowexplicitkindsignaturesontypeparameters:
andsoon.SeveralverysuccessfulC++libraries,suchastheStan-
classC awhere
dardTemplateLibrary[29]andtheBoostGraphLibrary[28],pro-
typeS a(k :: ⋆→⋆) :: ⋆
vide highly-parameterised interfaces to these generic data struc-
Instancedeclarationsmustgiveadefinitionforeachassociatedtype
tures,alongwithawiderangeofimplementationsoftheseinter-
synonymoftheclass,unlessthesynonymhasbeengivenadefault
faceswithdifferentperformancecharacteristics.Recently,Garcia
definition in the class declaration. The definition in an instance
et al. [8] published a qualitative comparison of six programming
declarationlookslikethis:
2Theinfixoperatorf $x inHaskellisfunctionapplicationf x atalesser instanceC [a]where
precedence. typeS [a]k = (a, k a)
The part to the left of the “=” is called the definition head. The tractable.Inparticular,theymustbeconfluent;i.e.,ifatypeexpres-
head must repeat the type parameters of the instance declaration sion can be reduced in two different ways, there must be further
exactly(here[a]);andanyadditionalparametersofthesynonym reductionstepsthatjointhetwodifferentreductsagain.Moreover,
must be simply type variables (k, in our example). The overall type functions must be terminating; i.e., applications must reach
number of parameters, called the synonym’s arity, must be the anirreduciblenormalformafterafinitenumberofreductionsteps.
same as in the class declaration. All applications of associated Thefirstcondition,confluence,isalreadystandardonthelevelof
typesynonymsmustbesaturated;i.e.,suppliedwithasmanytype values,butthesecond,termination,isaconsequenceofthedesire
argumentsasprescribedbytheirarity. tokeeptypecheckingdecidable.
Weomitherethediscussionoftopleveldatatypedeclarations Similar requirements arise already for vanilla type classes as
involving associated types, as we covered these in detail previ- partofaprocessknownascontextreduction.Inadeclaration
ously [1]. In all syntactic restrictions in this section, we assume instance(π1, ..., πn) ⇒ C τ1···τm
thatanytopleveltypesynonymshavealreadybeenreplacedbytheir
right-handsides. we call C τ1···τm the instance head and (π1,..., πn) the in-
stancecontext,whereeachπi isitselfaclassconstraint.Suchan
3.1 Equalityconstraints instancedeclarationimpliesacontextreductionrulethatreplaces
theinstanceheadbytheinstancecontext.Thecriticalpointisthat
Suppose we want to write a function sumColl that adds up the
elementsofacollectionwithintegerelements.Itcannothavetype the constraints πi can directly or indirectly trigger other context
reductionrulesthatproduceconstraintsinvolvingCagain.Hence,
sumColl :: (Collectsc) ⇒ c → Int --Wrong! wehaverecursivereductionrulesandthesameissuesofconfluence
sumCollc = sum(toListc) andterminationasforassociatedtypesynonymsarise.Haskell98
becausenotallcollectionshaveIntelements.Weneedtoconstrain carefullyrestrictstheformationrulesforinstancedeclarationssuch
c torangeonlyoverInt-elementcollections.Thewaytoachieve thattheimpliedcontextreductionrulesareconfluentandterminat-
thisistouseanequalityconstraint: ing. It turns out, that we can use the same restrictions to ensure
sumColl :: (Collectsc, Elemc = Int) ⇒ c → Int thesepropertiesforassociatedtypesynonyms.Inthefollowing,we
sumCollc = sum(toListc) discuss these restrictions, but go beyond Haskell 98 by allowing
multi-parameter type classes. We will also see how the standard
Asanotherexample,supposewewantedtomergetwocollections,
formationrulesforinstancesaffectthetypefunctionsinducedby
perhapswithdifferentrepresentations,butwiththesameelement
associatedsynonymdefinitions.
type.Thenagain,weneedanequalityconstraint:
Restrictionsoninstanceheads. Haskell98imposesthefollow-
merge :: (Collectsc1, Collectsc2, Elemc1 = Elemc2)
ingthreerestrictions.Restriction(1):Headsmustbeconstructor-
⇒ c1 → c2 → c2
based;i.e.,thetypepatternsintheheadmayonlycontainvariables
mergec1c2 = foldr insertc2(toListc1)
and data type constructors, synonyms are not permitted. Restric-
Without loss of generality, we define an equality constraint to
tion (2): Heads must be specific; i.e., at least one type parameter
have the form (S α τ = υ), where S is an associated type syn-
mustbeanon-variableterm.Restriction(3):Headsmustbenon-
onym, α are as many type variables as the associated class has
overlapping; i.e., there may be no two declarations whose heads
parameters, and the τ and υ are arbitrary monotypes. There is
areunifiable.
no need for greater generality than this; for example, the con-
Given that the heads of associated synonyms must repeat the
straint ([S a] = [Int]) is equivalent to (S a = Int); the con-
type parameters of the instance head exactly, the above three re-
straint ([S a] = Bool) is unsatisfiable; and (a = Int) can be
strictionsdirectlytranslatetoassociatedsynonyms.Restriction(1)
eliminated by replacing a by Int. These restrictions are stronger
isfamiliarfromthevaluelevel,andwewilldiscussRestriction(2)
than they would have to be. However, they allow us later on to
alittlelater.ThevaluelevelavoidsRestriction(3)bydefiningthat
characterisewell-formedprogramsonapurelysyntacticallevel.
the selection of equations proceeds in textual order (i.e., if two
3.2 Constraintsforassociatedtypesynonyms equationsoverlap,thetextuallyearliertakesprecedence).However,
thereisnoclearnotionoftextualorderforinstancedeclarations,
Doesthistypesignaturemakesense?
whichmaybespreadovermultiplemodules.
funnyFst :: (Elemc, c) → Elemc
Restrictionsoninstancecontexts. Haskell98imposesonemore
Recall that Elem is a partial function at the type level, whose restriction. Restriction (4): Instance contexts must be decreasing.
domain is determined by the set of instances of Collects. So it More specifically, Haskell 98 requires that the parameters of the
onlymakessensetoapplyfunnyFstatatypethatisaninstanceof constraints πi occurring in an instance context are variables. If
Collects.Hence,werejectthesignature,requiringyoutowrite we have multi-parameter type classes, we need to further require
funnyFst :: Collectsc ⇒ (Elemc, c) → Elemc that these variable parameters of a single constraint are distinct.
toconstrainthetypesatwhichfunnyFst canbecalled.Morepre- Restriction(4)and(2)worktogethertoguaranteethateachcontext
cisely,eachuseofanassociatedtypesynonyminaprogrammer- reductionrulesimplifiesatleastonetypeparameter.Astypeterms
writtentypesignaturegivesrisetoaclassconstraintforitsasso- arefinite,thisguaranteesterminationofcontextreduction.
ciatedclass;andthatconstraintmustbesatisfiedbythecontextof In the presence of associated types, we generalise Restric-
thetypesignature,orbyaninstancedeclaration,oracombination tion(4)slightly.Assumingǫ1,...,ǫn areeacheitheratypevari-
ofthetwo.Thisvaliditycheckforprogrammer-suppliedtypean- ableoranassociatedtypeappliedtotypevariables,acontextcon-
notations is conveniently performed as part of the kind checking straintπicaneitherbeaclassconstraintoftheformDǫ1···ǫn or
oftheseannotations,aswewillseeinSection4.Kindcheckingis beanequalityconstraintoftheformS α1···αm = τ.
onlyrequiredforprogrammer-suppliedtypeannotations,because Theright-handsidesoftheassociatedtypesynonymsofanin-
inferredtypeswillbewell-kindedbyconstruction. stance are indirectly constrained by Restriction (4), as they may
onlycontainapplicationsofsynonymswhoseassociatedclassap-
3.3 Instancedeclarations pearsintheinstancecontext.So,ifwehave
Giventhatassociatedtypesynonymsamounttofunctionsontypes, instance(π1, ..., πn) ⇒ C τ where
weneedtorestricttheirdefinitionssothattypecheckingremains typeSC τ = [SD α]
and SD is associated with class D, then one of the πi must be So, just as in Haskell 98, a type is unconditionally ambiguous if
Dα.Inotherwords,asaconsequenceoftheinstancecontextre- oneofitsconstraintsmentionsnotypevariablethatisfreeinthe
striction, associated synonym applications must have parameters valuepartofthetype.
thatareeitherdistinctvariablesorothersynonymsappliedtovari- Thereisawrinkle,however.Considerthisfunction:
ables.Hence,thereductionofassociatedsynonymapplicationster- poss3 :: (C a) ⇒ S a → S a
minatesforthesamereasonthatcontextreductionterminates.
It looks unambiguous, since a is mentioned in the value part of
Thismightseemalittlerestrictive,butisinfactsufficientfor
thetype,butitisactuallyunconditionallyambiguous.Supposewe
mostapplications.Strictlyspeakingwe,andHaskell98,couldbe
apply poss3 to an argument of type Int. Can we deduce what a
a bit more permissive and allow that if there are n occurrences
is?Bynomeans!TheremightbemanyinstancedeclarationsforC
of data type constructors in the type parameters of an instance
thatallimplementS asInt:
head,eachconstraintintheinstancecontextmayhaveupton−1
occurrencesofdatatypeconstructorsinitsarguments.Moreover, instance... ⇒ C τ where
we may permit repeated variable occurrences if the type checker typeS τ = Int
terminatesonceitseesthesameconstrainttwiceinonereduction (Infact,thissituationisnotnew.EveninHaskell98wecanhave
chain. Work on term rewriting system (TRS) [19] has identified degeneratetypesynonymssuchas
manypossiblecharacterisationsofsystemsthatareguaranteedto typeS a = Bool
beconfluentandterminating,buttherestrictionsstatedaboveseem
whichwouldrenderposs3ambiguous.)
tobeaparticularlygoodmatchforafunctionallanguage.
The conclusion is this: When computing unconditional ambi-
guity—to emit earlier and more-informative error messages—we
3.4 Ambiguity shouldignoretypevariablesthatoccurunderanassociatedtype
synonym.Forposs3,thismeansthatweignorethea inS a,and
Thiscelebratedfunctionhasanambiguoustype:
hence, there is no occurrence of a left to the right of the double
echo :: (Reada, Show a) ⇒ String → String
arrow,whichrendersthesignatureunconditionallyambiguous.An
echos = show (reads)
important special case is that of class method signatures: Each
Thetroubleisthatneitherargumentnorresulttypemention“a”,so method must mention the class variable somewhere that is not
anycalltoechowillgiverisetotheconstraints(Reada, Show a), underanassociatedsynonym.Forexample,thisdeclarationdefines
with no way to resolve a. Since the meaning of the program de- anunconditionally-ambiguousmethodop,andisrejected:
pendsonthisresolution,Haskell98requiresthatthedefinitionis
classC awhere
rejectedasambiguous.
typeS a
The situation is much fuzzier when functional dependen-
op :: S a → Int
cies[15]areinvolved.Consider
classC ab | a → bwhere
...
poss :: (C ab, Eqb) ⇒ a → a 4. TheTypeSystem
Is the type of poss ambiguous? It looks like it, because b is not Inthissection,weformaliseatypesystemforalambdacalculus
mentioned in the type after the “⇒”. However, because of the including type classes with associated type synonyms. This type
functional dependency, fixing a will fix b, so all is well. But system is based on Jones’ Overloaded ML (OML) [13, 14] and
the dependency may not be so obvious. Suppose class D has no isrelatedtoourearliersystemforassociateddatatypes[1].Like
functionaldependency,butithasaninstancedeclarationlikethis: Haskell98[9,7],ourtypingrulescanbeextendedtogiveatype-
classDpqwhere directed translation of source programs into an explicitly-typed
... lambdacalculusakintothepredicativefragmentofSystemF.We
instanceC ab ⇒ D[a]bwhere omittheseextendedruleshere,astheextensioncloselyfollowsour
... earlierworkonassociateddatatypes[1].
poss2 :: (Dab, Eqb) ⇒ a → a The key difference between type checking in the presence of
Now, suppose poss2 is applied to a list of integers. The call will associated data types compared to associated type synonyms is
giverisetoaconstraint(D[Int]t),whichcanbesimplifiedbythe the treatment of type equality. In the conventional Damas-Milner
instancedeclarationtoaconstraint(C Intt).Nowthefunctional systemaswellasinitsextensionbytypeclasseswithassociated
dependencyforC willfixt,andnoambiguityarises.Inshort,some data types, type equality is purely syntactic—i.e, types are equal
callstoposs2maybeambiguous,butsomemaynot. ifftheyarerepresentedbythesameterm.Whenweaddassociated
Itdoesnoharmtodelayreportingambiguity.Nounsoundness typesynonyms,typeequalitybecomesmoresubtle.Moreprecisely,
arises from allowing even echo to be defined; but, in the case of theequationsdefiningassociatedtypesynonymsinclassinstances
echo, every single call will result in an ambiguity error, so it is refinetypeequalitybyintroducingnon-freefunctionsovertypes.
better to reject echo at its definition. When the situation is less ThetreatmentofthisrichernotionofequalityinaDamas-Milner
clear-cut,itdoesnoharmtoacceptthetypesignature,andreport systemwithtypeclassesduringtypecheckingandtypeinference
errors at the call site. Indeed, the only reason to check types for constitutesthemaintechnicalcontributionofthispaper.
ambiguity at all is to emit error messages for unconditionally-
ambiguousfunctionsattheirdefinitionratherthanattheiruse.
Associated type synonyms are easier, because functionally- 4.1 Syntax
dependenttypesarenotnamedwithaseparatetypevariable.Here The syntax of the source language is given in Figure 1. We use
is how class C and poss would be written using an associated overbarnotationextensively.Thenotationαnmeansthesequence
synonymS insteadofafunctionally-dependenttypeparameter: α1···αn;the“n”maybeomittedwhenitisunimportant.More-
classC awhere over, we use comma to mean sequence extension as follows:
typeS a an,an+1 , an+1.Althoughwegivethesyntaxofqualifiedand
poss :: (C a, Eq(S a)) ⇒ a → a quantifiedtypesandconstraintsinanuncurriedway,wealsosome-
η,thesaturatedapplicationofanassociatedtype.Notethatsucha
SymbolClasses saturatedapplicationcanbeofhigherkind,iftheresultkindκin
α,β,γ → htypevariablei thedefiningtsigisnot⋆.
T → htypeconstructori InthesyntaxofFigure1,andinthefollowingtypingrules,we
Sk → hassociatedtypesynonym,arityki maketwosimplifyingassumptionstoreducethenotationalburden:
D → htypeclassi
x,f,d → htermvariablei 1. Eachclasshasexactlyonetypeparameter,onemethod,andone
associatedtypesynonym.
Sourcedeclarations 2. There are no default definitions, neither for methods nor syn-
pgm → cls; inst; val (wholeprogram) onyms.Aprogramwithdefaultdefinitionscanberewritteninto
cls → class∀α.D′α⇒Dαwhere (classdecl) onewithout,byduplicatingthedefaultsatinstancesnotprovid-
ingtheirownversions.
tsig; vsig
inst → instance∀α.φwhere (instancedeclaration) 3. We elide all mention of kinds, as we exactly follow Jones’
atype; val systemofconstructorclasses[14].
val → x = e (valuebinding)
Lifting the first restriction is largely a matter of adding (a great
tsig → typeSkαk (assoc.typesignature)
many)overbarstothetypingrules.
vsig → x::σ (methodsignature)
atype → typeSkτ β(k−1) = ξ (assoc.typesynonym) 4.2 Typechecking
Figures2and3presentthetypingrulesforourtypesystem.Our
Sourceterms
formalisationissimilarto[9]inthatwemaintainthecontextreduc-
e → x|e e |λx.e|letx=e ine |e::σ
1 2 1 2
tionrulesaspartoftheinstanceenvironment.Themainjudgement
has the conventional form Θ|Γ ⊢ e:σ meaning “in type envi-
Sourcetypes
ronment Γ, and instance environment Θ, the term e has type σ”.
τ,ξ → T |α|τ τ |η (monotype)
1 2
η → Skτk (associatedtype) DeclarationsaretypedbyFigure3,wherealltherulesarestandard
forHaskell,exceptforRule(inst).
ρ → π⇒τ (qualifiedtype)
The instance environment Θ is a set of constraint schemes θ
σ → ∀α.ρ (typescheme)
that hold in e. A constraint scheme θ takes one of two forms
(Figure1):itiseitheraclassconstraintscheme∀α.φ,oranequality
Constraints
πc → Dτ (classconstraint) scheme ∀α.π=. The instance environment is populated firstly by
classandinstancedeclarations,whichgenerateconstraintschemes
π= → η=τ (equalityconstraint)
π → πc|π= (simpleconstraint) usingtherulesofFigure3;andsecondlybymovingunderneatha
φ → π⇒πc (qualifiedconstraint) qualifiedtype(rule(⇒I)ofFigure2).Thelatteraddsonlyasimple
θ → ∀α.φ|∀α.π= (constraintscheme) constraint π, which can be a class constraint πc or an equality
constraintπ=;thesesimpleconstraintsarespecialcasesofthetwo
formsdescribedearlier3.
Environments
ThetypingrulesarealmostasforvanillaHaskell98,withtwo
Γ → x:σ (typeenvironment)
major differences. The first is in the side conditions Θ ⊢ σ that
Θ → θ (instanceenvironment)
checkthewell-formednessoftypes,inrules(→I)and(∀E),for
U → π= (setofequalityconstraints)
reasonswediscussedinSection3.2.Therulesforthisjudgement
are also in Figure 2. The judgement needs the instance environ-
Figure1:Syntaxofexpressionsandtypes
mentΘsothatitcancheckthewell-formednessofapplicationsof
associated-type applications (Rule (wfsyn)), using the entailment
judgement Θ (cid:13) θ described below. In the interest of brevity, the
timesuseequivalentcurriednotation,thus:
presented rules elide all mention of kinds, leaving only the well-
πn ⇒τ ≡ π1 ⇒···⇒πn ⇒τ formednesscheckthatisdistinctivetoasystemincludingassoci-
τn →ξ ≡ τ1 →···→τn →ξ atedtypes.Moredetailsconcerningtheimplicationsofthejudge-
∀αn.ρ ≡ ∀α1···∀αn.ρ mentΘ ⊢ σareinourpreviouswork[1].Itisworthwhiletonote
that Rule (sig) does not contain well-formedness judgement, al-
We accommodate function types τ → τ by regarding them
1 2
thoughitmentionsauser-suppliedtype.Thistypeisalsoproduced
as the curried application of the function type constructor to two
bythetypingjudgementinthehypothesis,andthejudgemental-
arguments, thus (→) τ τ . We use (Fv x) to denote the free
1 2
waysproduceswell-formedtypes.So,therulewillneverapplyto
variablesofastructurex,whichmaybeanexpression,typeterm,
amalformedtype.
orenvironment.
ThesecondmajordifferenceisRule(conv),whichpermitstype
The unusual features of the source language all concern as-
sociated type synonyms. A class declaration may contain type conversion between types τ1 and τ2 if we have Θ (cid:13) τ1 =τ2.
The auxiliary judgement Θ (cid:13) θ defines constraint entailment,
declarationsaswellasmethodsignatures,andcorrespondinglyan
whichinHaskell98onlyhandlestypeclasses,butwhichweextend
instance declaration may contain type definitions as well as
herewithadditionalrulesfortypeequalityconstraints.Theserules
methodimplementations.Thesetypesynonymsaretheassociated
are also given in Figure 2 and include the four standard equality
typesynonymsoftheclass,andaresyntacticallydistinguished:Sis
anassociatedtypesynonymconstructor,whileT isaregulartype axioms (eqrefl), (eqsymm), (eqtrans), and (eqsubst). The last of
theseallowsequaltypestobewrappedinanarbitrarycontext:for
constructor(suchaslistsorpairs).Inthedeclarationofanassoci-
atedtypesynonym,thetypeindexescomefirst.Thearityofatype example,ifτ2 =τ3,thenTree(Listτ2) = Tree(Listτ3).
synonymisthenumberofargumentsgiveninitsdefiningtsig.The
arityisgivenbyasuperscripttotheconstructorname,butwedrop 3Rule(⇒I),andthesyntaxoftypes,doesnotallowonetoquantifyover
itwhenitisclearfromthecontext.Thesyntaxoftypesτ includes constraintschemes,anorthogonalandinterestingpossibleextension[11].
Θ | Γ ⊢ e : σ
(x:σ)∈Γ (var) Θ1|Γ⊢e1:σ1 Θ2|Γ[x:σ1]⊢e2:σ2(let) Θ|Γ⊢e:τ1 Θ(cid:13)τ1=τ2(conv)
Θ|Γ⊢x:σ Θ1,Θ2|Γ⊢letx=e1ine2:σ2 Θ|Γ⊢e:τ2
Θ|Γ[x:τ1]⊢e2:τ2 Θ⊢τ1(→I) Θ|Γ⊢e1:τ2→τ1 Θ|Γ⊢e2:τ2(→E)
Θ|Γ⊢λx.e2:τ1→τ2 Θ|Γ⊢e1e2:τ1
Θ,π|Γ⊢e:ρ Θ|Γ⊢e:π⇒ρ Θ(cid:13)π
(⇒I) (⇒E)
Θ|Γ⊢e:π⇒ρ Θ|Γ⊢e:ρ
Θ|Γ⊢e:σ α6∈FvΘ∪FvΓ Θ|Γ⊢e:∀α.σ Θ⊢τ Θ|Γ⊢e:σ Fvσ=∅
(∀I) (∀E) (sig)
Θ|Γ⊢e:∀α.σ Θ|Γ⊢e:[τ/α]σ Θ|Γ⊢(e::σ):σ
Θ (cid:13) θ
θ∈Θ Θ(cid:13)∀α.θ Θ(cid:13)π⇒φ Θ(cid:13)π
(mono) (spec) (mp)
Θ(cid:13)θ Θ(cid:13)[τ/α]θ Θ(cid:13)φ
Θ(cid:13)τ =τ(eqrefl) ΘΘ(cid:13)(cid:13)ττ12==ττ21(eqsymm)
Θ(cid:13)τ1=Θτ(cid:13)2 τ1=Θτ(cid:13)3 τ2=τ3(eqtrans) Θ(cid:13)[τ1/Θα](cid:13)π [τ2/Θα](cid:13)π τ1=τ2(eqsubst)
Θ ⊢ σ
Θ⊢τi Θ(cid:13)ΘD⊢τ0SkSτ0isτa(nk−as1s)ociatedtypeofD(wfsyn) Θ⊢σΘ⊢∀αα.6∈σFvΘ(wfspec) ΘΘ⊢,ππ⊢⇒ρρ(wfmp)
Θ⊢τ1 Θ⊢τ2(wfapp) (wfvar) (wfcon)
Θ⊢τ1τ2 Θ⊢α Θ⊢T
Figure2:Typingrulesforexpressions
Θ | Γ ⊢ cls : Θ,Γ
Θ,Dα⊢σ
(cls)
class∀α.D′αn ⇒Dαwhere
Θ|Γ⊢ typeSαβ ::κ :[∀α.Dα⇒D′αn],[f :∀α.Dα⇒σ]
f ::σ
Θ ,Θ | Γ ⊢ inst : Θ
c i
foreachD′where(∀δ.Dδ⇒D′δ)∈Θc,wehaveΘc,Θi (cid:13)∀α.π⇒D′τ
Θc,π⊢ξ (f :∀γ.Dγ ⇒σ)∈Γ Θc,Θi,π|Γ⊢e:[τ/γ]σ
(inst)
instance∀α.π⇒Dτ where
Θc,Θi |Γ⊢ typeSτ β =ξ :[∀α.π⇒Dτ,∀α.Sτ β =ξ]
f =e
Θ | Γ ⊢ val : Γ ⊢ pgm
Θ|Γ⊢e:σ (val) Θ=Θc,Θi Γ=Γc,Γv
Θ|Γ⊢(x=e):[x:σ] Θ|Γ⊢cls:Θc,Γc Θ|Γ⊢inst:Θi Θ|Γ⊢val:Γv
⊢cls;inst;val
Figure3:Typingrulesfordeclarations
MuchofthisisstandardforextensionsoftheHindley-Milner Inthissection,afterfixingsomeconstraintsonsourceprograms,
system with non-syntactic type equality [24, 22, 21, 23, 32, 2]. wewillfirstdiscussavariantofHindley-Milnertypeinferencewith
Novelinoursystemistheintegrationofentailmentoftypeclass predicates.Theinferencealgorithmdependsonaunificationpro-
predicates with type equalities. In particular, our system allows cedurethatincludestypenormalisation(Section5.3).Afterwards,
equalityschemes,suchas wewillusetheunificationproceduretotestthesubsumptionrela-
∀a.Sprintf (I a) = Int → Sprintf a tionoftypeschemes(Section5.4).Weconcludethesectionwith
someformalpropertiesofourinferencesystemforassociatedtype
intheconstraintcontextΘofthetypingrules.Equalityschemesare
synonyms.
introducedbyRule(inst)ofthedeclarationtypingrulesfromFig-
ure3.Thisruleturnsthedefinitionsofassociatedtypesynonyms
5.1 Well-formedprograms
into equality schemes, such as the Sprintf scheme above, which
areusedintheinferencerulesofjudgementΘ(cid:13)θfromFigure2. To achieve decidable type inference computing principal types,
Animportantpropertyofthesystemisthatthewell-formedness we impose the following restrictions on the source programs as
of types is invariant under the expansion of associated type syn- producedbyFigure1(cf.,Restrictions(1)to(4)inSection3):
onyms.Specifically,Rule(inst)ensuresthateachequalityscheme
• Instance heads must be constructor-based, specific, and non-
∀α.S τ β = ξ ispairedwithaclassconstraintscheme∀α.π ⇒
overlapping.
Dτ, where D is the class S is associated with. Hence, all the
premisesπforthevalidityofξarefulfilledwhenevertheequality • Instancecontextsmustbedecreasing.
isapplicable.Rule(inst)ensuresthiswiththepremiseΘc,π ⊢ξ. Toguaranteeacoherent(i.e.,unambiguous)translationofwell-
Letusconsideranexample:TheFormat classofSection2.1has
typedsourceprogramstoanexplicitly-typedlanguageinthestyle
aninstance
of System F, which implements type classes by dictionaries, we
instanceFormata ⇒ Format(I a)where requiretwofurtherconstraints:
typeSprintf (I a) = Int → Sprintf a
• Equalityconstraints(inprogrammer-suppliedtypeannotations)
Hence,Rule(inst)addsthetwoconstraintschemes
mustbeoftheformSατ =ξ(i.e.,thefirstargumentmustbe
θC = ∀a.Formata ⇒ Format(I a) atypevariable).
θ = ∀a.Sprintf (I a) = Int → Sprinfta
= • Ifσ≡(∀α.π⇒τ)isamethodsignatureinaclassdeclaration
tothecontextΘ.Nowconsideranexpressioneoftype forDβ,werequirethatβ 6∈Fvπ.
Format(I String) ⇒ Char → Sprintf (I String)
(These restrictions are not necessary if the semantics of the pro-
NotethatthecontextFormat(I String)isrequiredforthetype
gramisgivenbytranslationtoanuntypedintermediatelanguage,
to be well-formed according to judgement Θ ⊢ σ. In order to
orperhapsonewitharichertypesystemthanSystemF;seeforex-
remove the constraint Format(I String) from the type of e by
ample [30].) Finally, to stay with Haskell’s tradition of rejecting
Rule (⇒E), we need to have Θ (cid:13) Format(IString), which
unconditionally-ambiguous type signatures, in the sense of Sec-
accordingtoθC andRule(mp)requiresΘ(cid:13)FormatString. tion3.4,werequiretwomoreconstraints:
The result of applying θ to Char → Sprintf (I String),
=
i.e., Char → Int → Sprintf String, is well-formed only if • Ifσ≡(∀α.π⇒τ)isamethodsignatureinaclassdeclaration
Θ(cid:13)FormatStringholds.ThatitholdsisenforcedbyθC. forDβ,werequirethatβ ∈Fixvσ.
There are two more noteworthy points about Rule (inst).
• Similarly,werequireofallsignaturese::∀α.ρthatα∩Fvρ⊆
Firstly,therulechecksthatthesuperclassconstraintsoftheclass
Fixvρ.
D are fulfilled in the first premise. Secondly, when checking the
validityoftheright-handsideoftheassociatedsynonym,namelyξ, HereFixvσ,thesetoffixedvariablesofasignatureσ,isdefined
weassumeonlyΘc(thesuperclassenvironment).Ifwewouldadd asfollows:
Θi,wewouldviolateRestriction(4)ofSection3.3andpotentially Fixv T = {}
allownon-terminatingsynonymdefinitions. Fixv α = {α}
Fixv(τ τ ) = Fixvτ ∪Fixvτ
1 2 1 2
Fixv η = {}
5. TypeInference
Fixv((η=τ)⇒ρ)= Fixvτ ∪Fixvρ
The addition of Rule (conv) to type expressions and of equality Fixv(Dτ ⇒ρ) = Fixvρ
axioms to constraint entailment has a significant impact on type Fixv(∀α.σ) = Fixvσ\{α}
inference.Firstly,weneedtonormalisetypetermsinvolvingasso- Intuitively, the fixed variables of a type (or signature) are those
ciatedtypesaccordingtotheequationsdefiningassociatedtypes. freevariablesthatwillbeconstrainedwhenweunifythetype(or
Secondly,typetermsinvolvingtypevariablesoftencannotbecom- typecomponentofthesignature)withagroundtype;providedit
pletely normalised until some type variables are further instanti- matches.
ated. Consequently, we need to extend the standard definition of Aprogramthatmeetsallofthelistedconstraintsiswell-formed.
unificationintheHindley-Milnersystemtoreturnpartially-solved ThedeclarationtypingrulesofFigure3determine,foragivenpro-
equalityconstraintsinadditiontoasubstitution. gram,thevalidityofaprogramcontextΘP andtypingenvironment
Toillustratethis,reconsiderthedefinitionoftheclassCollects Γ.Bothareinputstotypeinferenceforexpressionsand,iftheyare
withassociatedtypeElemfromSection1.Theunificationproblem withoutsuperfluouselements,wecallthemwell-formed.Asinthe
(Int, a) = (Elemc, Bool) implies the substitution [Bool/a], typing rules, we implicitly assume all types to be well-kinded. It
but also the additional constraint Int = Elemc. We cannot de- isstraight-forwardtoaddthecorrespondingjudgementstothepre-
cide whether the latter constraint is valid without knowing more sentedrules.
aboutc,sowecallsuchconstraintspendingequalityconstraints.In Wecallanexpressionwell-formedifanysignatureannotation
thepresenceofassociatedtypes,thetypeinferencealgorithmhas of the form (e :: σ) obeys the listed constraints. For the rest of
tomaintainpendingequalityconstraintstogetherwithclasspredi- thepaper,weconfineourselvestowell-formedprograms,program
cates. contexts,typingenvironments,andexpressions.Thisinparticular
meansthattherewritesystemimpliedbytheequalityschemesina repeated application of one-step unification, as performed by the
programcontextΘP isconfluentandterminating. reflexiveandtransitiveclosureΘ (cid:13)U U ∗ U′;R,reducesaset
of equality constraints U to a set of pending equality constraints
5.2 Typeinference U′ andasubstitutionR.IfU′ cannotbereducedanyfurther,we
We begin with type inference for type classes with associated alsowriteΘ(cid:13)U U ! U′;R,henceturningthetransitiveclosure
types. Figure 4 displays the rules for the inference judgement ofone-stepunificationintoadeterministicfunction.Notethat,due
Θ,U |TΓ⊢W e:τ.GivenatypeenvironmentΓandanexpression tothesyntacticrestrictionsonτ,Rule(appU)and(redU)arenot
overlapping.
e as inputs, it computes the following outputs (1) a set of class
UnificationisperformedunderaconstraintenvironmentΘonly
constraints Θ, (2) a set of pending equality constraints U, (3) a
because this environment is required by associate type synonym
substitution T, and (4) a monotype τ. The judgement implicitly
expansion.Itiseasytoseethat,wheretwotypesτ andτ arefree
athlseoindsetpanencedsdeocnlatrhaetiopnrosgarnadmrecmonatienxstcΘonPs,tainntittihaellryeapftoepr.uBlaetecdaubsye of associated synonyms, the relation • (cid:13)U {τ1 =1 τ2} 2 ! •;R
coincideswithstandardsyntacticunificationasemployedintype
class and instance declarations are, in effect, explicitly typed,
inferenceforvanillaHaskell98.
theirtypeinferencerulesareextremelysimilartothoseinFigure3;
JustlikeJones[14],weonlyneedfirst-orderunificationdespite
so,wedonotgivethemseparatelyhere.
thepresenceofhigher-kindedvariables,aswerequireallapplica-
Our inference rules generalise the standard rules for Haskell
tionsofassociatedtypesynonymstobesaturated.
in two ways: (1) the inference rules maintain a set of equality
constraintsUand(2)unificationproducesasetofpendingequality
Soundnessofunification. ThejudgementsofFigure5enjoythe
constraintsinadditiontoasubstitution.Letuslookatbothaspects
followingproperties.
insomemoredetail.
TypeinferenceforHaskellneedstomaintainasetofΘofcon- LEMMA1 (Soundnessoftypereduction). Given a well-formed
straints,calledtheconstraintcontext.InHaskell98,theconstraint constraintenvironmentΘandatypeτ withΘ ⊢ τ,wehavethat
contextisasetoftypeclasspredicates.Weextendthecontextto Θ(cid:13)τ τ′impliesΘ(cid:13)τ =τ′.
alsoincludeequalityconstraints,justasinthetypingrules.How-
ever,asweneedtotreatthesetwokindsofconstraintsdifferently LEMMA2 (Soundnessofone-stepunification). Givenawell-formed
duringtheinferenceprocess,wepartitiontheoverallcontextinto constraintenvironmentΘ,thejudgementΘ (cid:13)U τ1 =τ2 U;R
thetwosubsetsΘandUdenotingtheclassconstraintsandequality impliesthatΘ(cid:13)R(τ =τ )iffΘ(cid:13)U.
1 2
constraints,respectively.Hence,thephraseΘ,U totheleftofthe
verticalbarintheinferencejudgementcapturesthewholecontext. THEOREM1 (Soundnessofunification). Givenawell-formedcon-
wInhpicahrtiacruelaimr,pRliuclietsly(vpaarrtWiti)onaenddi(nstiogWthe)trwesoulctoimnpcoonnetenxtstsΘ[βa/nαd]πU, Ustr′a;iRntiemnpvliireosntmhaenttΘΘ(cid:13)anRdUaisfeftΘof(cid:13)eqUua′.litiesU,thenΘ(cid:13)U U ∗
in the hypotheses of other inference rules. During generalisation
The proofs proceed by rule induction. Moreover, Theorem 1 re-
bythefunctionGen(Γ;ρ)inRule(letW)and(sigW),bothclass quires that “Θ (cid:13) Rθ iff Θ (cid:13) Rθ ” follows from “Θ (cid:13) θ iff
andequalityconstraintsaremovedintothesignaturecontextofthe 1 2 1
Θ (cid:13) θ ”foranysubstitutionR,whichisabasicpropertyofcon-
producedsignature. 2
straintentailment.
In Rule (→EW), the two sets of equality constraints U1 and
U arebothextractedoutoftheconstraintcontext,tobefedtothe
2 5.4 Subsumption
unificationprocessinconjunctionwiththenewequalityconstraint
T τ = τ → α. Unification simplifies the equalities as far as To handle type annotations, such as in expressions of the form
2 1 2
possible,producing,inadditiontoasubstitutionR,asetofpending e::σ,duringtypeinference,weneedtohaveanalgorithmdeciding
equality constraints U. This set is used in the conclusion of the typesubsumption.Wesayatypeschemeσ1subsumesσ2,written
inferencerule. σ ≤ σ iff any expression that can be typed as σ can also be
1 2 1
Rules (→EW) and (sigW) make use of two auxiliary judge- typedasσ2.
mentsforunificationandsubsumption,respectively.Bothofthese Thesubsumptioncheckcanbeformulatedasaconstraintentail-
judgementsdependontheprogramcontextΘP andarethesubject mentprobleminthepresenceofequalityconstraints.Ifwewantto
ofthefollowingtwosubsections. check
(∀α .π ⇒τ )≤(∀α .π ⇒τ ),
5.3 Unification 1 1 1 2 2 2
Associated type synonyms extend Haskell 98’s purely syntactic in the context of a program context ΘP, we need to demonstrate
that,givenasetofnewtypeconstructorsT oftheappropriatekind,
type equality; e.g, ElemBitSet = Char holds under the defi-
nitions for the class Collects discussed before. To handle non- thereexistsasubstitutionR=[ξ/α1],suchthat
swyenltla-fcotircmeeqduaplriotigersadmusr.inIgnupnairfiticcautiloarn,,twheeetyxppeloiftutnhcetipornospeinrtiweselolf- ΘP,[T/α2]π2 (cid:13)Rπ1,Rτ1 =[T/α2]τ2
formed programs are confluent and terminating; i.e., type terms wherewedefinetheentailmentofasetofpredicatesΘ(cid:13)θasthe
haveuniquenormalforms.Hence,wecandeterminewhethertwo conjunctionofallΘ(cid:13)θi.
typetermsareequalbysyntacticallycomparingtheirnormalforms. Giventhatweimplementtheentailmentofequalitiesbyunifi-
ThejudgementΘ(cid:13)τ τ′,whoseinferencerulesaregivenby cationduringtypeinference,itisnotsurprisingthatwecanimple-
Figure5,definesaone-stepreductionrelationontypetermsunder mentsubsumptionviaacombinationofunificationandtheusual
aconstraintenvironmentΘ.Thereductionrelationontypesisused backchainingapproachtoentailment;aprocesscalledcontextre-
by the one-step unification judgement Θ (cid:13)U τ1 =τ2 U;R. ductionwhenusedtosimplifytypeclasscontexts.InFigure6,we
Thisjudgementholdsforanequalityτ =τ iffthecorresponding define the procedure computing entailment using the same struc-
1 2
unificationproblemcanbereducedtoasimplerunificationproblem ture as we used for the unification procedure: Firstly, we define
in the form of a set of equality constraints U and a substitution a one-step entailment judgement Θ (cid:13)E π P;R that reduces
R.Thesymbol•intheinferencerulesrepresentsanemptysetof a constraint π (which may be a class constraint or equality con-
equalityconstraintsandtheidentitysubstitution,respectively.The straint) to a simpler set of constraints P and a substitution R.
W
Θ,U | TΓ ⊢ e : τ
(x:∀α.π⇒τ)∈Γ βfresh
W (varW)
[β/α]π|Γ⊢ x:[β/α]τ
αfresh
Θ1,U1 |T1Γ⊢W e1 :τ1 Θ2,U2 |T2(T1Γ)⊢W e2 :τ2 ΘP (cid:13)U U1,U2,(T2τ1 = τ2 →α) ! U;R
W (→EW)
R(T Θ ,Θ ),U |(RT T )Γ⊢ e e :Rα
2 1 2 2 1 1 2
W
Θ,U |TΓ[x:α]⊢ e:τ αfresh
W (→IW)
Θ,U |TΓ⊢ λx.e:Tα→τ
W W
Θ ,U |T Γ⊢ e :τ Θ ,U |T (T Γ[x:σ])⊢ e :τ σ=Gen(T Γ;(Θ ,U )⇒τ )
1 1 1 1 1 2 2 2 1 W 2 2 1 1 1 1 (letW)
Θ ,U |(T T )Γ⊢ (letx=e ine ):τ
2 2 2 1 1 2 2
βfresh
Θ,U |TΓ⊢W e:τ1 σ=Gen(TΓ;(Θ,U)⇒τ1) ΘP (cid:13)σ≤(∀α.π⇒τ2) Fv(π⇒τ2)⊆α(sig )
W W
[β/α]π|TΓ⊢ (e::∀α.π⇒τ ):[β/α]τ
2 2
Gen(Γ;ρ)=∀α.ρ ,where α=Fvρ\FvΓ
Figure4:Typeinferencerules
Θ (cid:13) τ τ′
Θ(cid:13)τ τ′ Θ(cid:13)τ τ′
1 1 (lapp ) 2 2 (rapp )
Θ(cid:13)τ τ τ′ τ R Θ(cid:13)τ τ τ τ′ R
1 2 1 2 1 2 1 2
1≤i≤k Θ(cid:13)τi τi′ τj′ =τj,∀j 6=i(arg ) (∀α.η=τ)∈Θ (syn )
Θ(cid:13)Skτk Skτ′k R Θ(cid:13)[ξ/α]η [ξ/α]τ R
Θ (cid:13) τ = τ U;R
U 1 2
Θ(cid:13)U τ =τ •;•(reflU) ΘΘ(cid:13)(cid:13)UU ττ12 ==ττ21 UU;;RR(symmU) Θ(cid:13)U αα=6∈τF vτ•;[τ/α](varU)
Θ(cid:13)η τ
Θ(cid:13)U τ1τ2 =τ1′ τ2′ {τ1 =τ1′,τ2 =τ2′};•(appU) Θ(cid:13)U η=τ1 {τ22=τ1};•(redU)
Θ (cid:13) U ∗ U′;R
U
Θ(cid:13)U τ1 =τ2 U′;R′ Θ(cid:13)U R′U,U′ ∗ U′′;R′′
Θ(cid:13)U U ∗ U;• Θ(cid:13)U U,τ1 =τ2 ∗ U′′;R′′R′
Figure5:Unificationinthepresenceoftypefunctions
Θ (cid:13) π P;R
E
Θ(cid:13)E(∀[αξ./πα]⇒DDτ τ)[∈ξ/Θα]π;•(bchainE) Θ(cid:13)EΘD(cid:13)ττ {Dτ′τ′};•(redE) ΘΘ(cid:13)(cid:13)EU ττ11 ==ττ22 UU;;RR(eqE)
Θ (cid:13) P ∗ P′;R
E
Θ(cid:13)U π P′;R′ Θ(cid:13)U R′P,P′ ∗ P′′;R′′
Θ(cid:13)U P ∗ P;• Θ(cid:13)U P,π ∗ P′′;R′′R′
Figure6:Constraintentailmentwithequalityconstraints
Rule(bchainE)formalisesstandardbackchaining,Rule(redE)en- 6. FunctionalDependencies
ablesthereductionofassociatedtypesynonymsinclassparame-
Associated type synonyms cover much the same applications as
ters,andRule(eqE)invokesone-stepunificationforequalitycon- functional dependencies. It is too early to say which of the two
straints. Secondly, we define the reflexive and transitive closure
is“better”;hence,wewillsimplycontrastthepropertiesofboth.
Θ (cid:13)E P ∗ P′;R. Finally, we turn the closure into a deter- The comparison is complicated by the existence of at least three
ministicfunctionbyrequiringthatforΘP (cid:13)E P ! P′;R,the variantsoffunctionaldependencies:(1)Thesystemdescribedby
resultingsetofconstraintsP′cannotbereducedfurther.
Mark Jones [15], (2) the generalised system implemented in the
Now,wecandefinesubsumptionasfollows:
Glasgow Haskell Compiler (GHC) [31], and (3) an even more
ΘP,[T/α2]π2 (cid:13)E {π1,τ1 =[T/α2]τ2} ! •;R permissivesystemformalisedbyStuckey&Sulzmann[30].Like
ourassociatedtypesynonyms,thefirsttwoofthesesystemspermit
T newtypeconstructors
(≤) animplementationbyadictionarytranslationtoanexplicitly-typed
ΘP (cid:13)(∀α1.π1 ⇒τ1)≤(∀α2.π2 ⇒τ2) languageakintoSystemF.StuckeyandSulzmann’ssystem,based
In other words, subsumption succeeds if context reduction can on an encoding into constraint handling rules, gains additional
resolvetheconstraintsetentirely. generality by giving up on a type-preserving translation and on
separatecompilation.
Soundness of subsumption. The subsumption rule enjoys the AspointedoutbyDucketal.[6],GHC’ssystemisnotdecid-
followingproperty. able,asitpermitsrecursiveinstancedeclarationsthat,forsomepro-
gramsthatshouldberejected,leadstonon-terminationoftypein-
LEMMA3 (Soundnessofsubsumption). LetΘP beawell-formed ference.Jonesoriginalsystemisdecidable.TheStuckey-Sulzmann
constraint environment, and σ1 = ∀α1.π1 ⇒ τ1 and σ2 = system,andtheassociatedtypesynonymswedescribehere,both
∀α2.π2 ⇒τ2signatureswithΘP (cid:13)σ1andΘP (cid:13)σ2,whereσ2is ensuredecidabilitybyasuitablesetofrestrictionsontheadmissi-
closed.Then,ΘP (cid:13) σ1 ≤σ2impliesthat,givenasetofnewtype bleconstrainthandlingrulesandassociatedtypesynonyms,respec-
constructorsT oftheappropriatekind,thereexistsasubstitution tively;bothsystemscanhandlemoregeneralrulesetsifdecidable
R=[ξ/α1],suchthatΘP,[T/α2]π2 (cid:13)Rπ1,Rτ1 =[T/α2]τ2. inferenceisnotrequired.
ThelemmaisanimmediateconsequenceofTheorem1.
6.1 Typesubstitutionproperty
5.5 Formalpropertiesoftypeinference
We usually require from a type system that, if we can type an
THEOREM2 (Soundnessoftypeinference). Assumeawell-formed
expression e with a type scheme ∀α.σ, then we can also type it
program context ΘP, typing environment Γ, and expression e. If withaninstance[τ/α]σ.Interestingly,thispropertydoesnothold
W
Θ,U |TΓ⊢ e:τ,then(ΘP,Θ,U)|TΓ⊢e:τ. forJones’andGHC’sversionoffunctionaldependencies.Hereis
anexample:
Inprovingthistheorem,wefollowedJones[12]whointroducesa
classC ab|a → bwhere
syntax-directedsystemasabridgebetweenthedeclarativetyping
foo :: a → b
rules and the algorithmic inference rules, as first suggested by
instanceC BoolIntwhere
Cle´ment at al. [3]. The tricky bit is to define the inference rule
fooFalse = 0
for function elimination in the syntax-directed system such that
fooTrue = 1
a correspondence to the inference system can be established. We
Underthesedefinitions,considerthefollowingthreesignaturesof
definetheruleasfollows:
thefunctionbar:
Θ|Γ⊢e :τ Θ|Γ⊢e :τ
ΘPΘ,1Θ|Γ(cid:13)1⊢τ1e1=eτ22:→τ1′ τ1′2 2 (→ES) bbbaaarrr :::::: CC aBool bb ⇒⇒BaBooooll →→→ Ibbnt ------(((312))).........amsupobpssltyt.gfieunnnset-ardanelcpetype
Inaddition,weneedtouseTheorem1andLemma3. bar = foo
Webelievethatourinferencealgorithmiscompleteandthatwe Withsignature(1)and(3)theprogramtypechecksfine,butwith
can obtain principal types by performing a further generalisation (2)itisrejectedbybothGHCandHugs.Thisisdespite(2)clearly
steponitsoutputs.However,weleavetheprooftofurtherwork— beingasubstitutioninstanceof(1),and(2)and(3)beingequivalent
whichweplantodobyagainfollowingJones’schemeforqualified (i.e.,eachonesubsumestheother).TheStuckey-Sulzmannsystem
types. acceptsallthreesignatures.