a thesissubmitted to
The University of Kent at Canterbury
in the subjet of omputer siene
for the degree
of dotor of philosophy.
By
Jan-GeorgSmaus
Thisthesisdealswithtwothemes: (1)onstrutionof abstratdomainsformode
anal-ysis of typed logi programs; (2) veriation of logi programs usingnon-standard
se-letion rules.
(1)Modeinformationisimportantmainlyforompileroptimisations. Thepreision
of a mode analysis depends partly on the expressiveness of the abstrat domain. We
show how speialised abstrat domains may be onstruted for eah type in a typed
logi program. These domains apture the degree of instantiation of a term very
pre-isely. The domain onstrution proedure is implemented using the Godel language
and tested on some example programsto demonstrate the viabilityand high preision
of theanalysis.
(2) We provide veriation methods for logi programs using seletion rules other
thantheusualleft-to-rightseletionrule. Weonsiderveaspetsofveriation:
termi-nation;andfreedomfrom(full)uniation,our-hek, oundering,and errorsrelated
to built-ins. The methodsarebased on assigninga mode,inputoroutput, to eah
ar-gumentpositionofeahprediate. Thismode isonlyxedwithrespettoa partiular
exeution. Fortermination,werstidentifyalassofprediateswhihterminateunder
the assumption that derivationsare input-onsuming, meaning that ineah derivation
step, the input arguments of the seleted atom do not beome instantiated.
Input-onsumingderivationsan berealisedusingblokdelarations,whihtest thatertain
argument positions of the seleted atom are non-variable. To show termination for
a program where not all prediates terminate under the assumption that derivations
are input-onsuming,we make thestronger assumptionthat derivationsare left-based.
This formalises the \default left-to-right" seletion rule of Prolog. To the best of our
knowledge, this work is the rst formal and omprehensive approah to this kind of
terminationproblem. The resultson the other four aspets are mainlygeneralisations
Iam gratefulto themanypeoplewho helpedmewritemyPhDthesis.
The researh of this thesis was partly arried out in the projet `Deteting and
ExploitingDeterminayinLogiPrograms'ledbyAndyKingattheUniversityofKent
at Canterbury and Pat Hill at the Universityof Leeds. Andy Kingwas also my PhD
supervisor. Iwould like to thank Andyand Pat fortheirritialguidane andfriendly
enouragement.
Iwasvery fortunatetobeamemberofthelogiprogramminggroupatthe
Univer-sitiesofLeeds and Kent. I wouldliketo thank FloreneBenoy,Andrew Heaton,Jaob
Howe and JonathanMartinfortheprodutive andenjoyable time we spenttogether.
I also thank Eerke Boiten, NaomiLindenstrauss,Fred Mesnardand ErikPoll,who
proofreadpartsofmythesis. MaartenSteenhasgivenmemuhadvieonorganisational
matters.
Many olleagues have inspired my work. I would like to mention Krzysztof Apt,
Tony Bowers, Henning Christiansen, Mihael Codish, Bart Demoen, Sandro Etalle,
Fergus Henderson,Lee NaishandSalvatore Ruggieri.
I gratefully aknowledge the nanial support from the EPSRC and the
Com-puting Laboratory of the University of Kent at Canterbury. During the rst two
years of my PhD studiesI was employed as a researh assoiate under EPSRC Grant
No.GR/K79635, and intheremaining time, Ireeived anE.B. SprattBursary.
I made many friendsduring thetimeI spent inCanterbury,most of them through
my `lunh group' or throughthe orhestra of Kent University. They have made these
three and a half years a wonderful time. When I leave Canterbury thissummer, I will
beome another outpost of this irle of friends whih already spans all over Europe,
and even further.
I amgratefulto myfamilyfortheirontinuingsupport. Lastbutnotleast,I thank
Modes and types are two widely used onepts in analysis and veriation of logi
programs. On the analysis side, modes and types allow us to inferinformation about
theprogramwhihisusefulforompileroptimisations,helpingtogeneratemoreeÆient
ode. Ontheveriationside,modesandtypesallowustoproveanumberofdesirable
properties of the program, suh as our-hek freedom and termination. Some logi
programming languages even go as far as only admitting programs that meet ertain
modeandtyperequirements. ThishasgreatbenetsintermsofeÆienyandreliability
of software.
The separations between the above areas are not learut. Moreover, the notions
of mode and type have diering meaningsdependingon theontext inwhih they are
used. Thereisa whole spetrumof suhmeanings.
This thesis treats two substantially dierent themes. However, both arerelated to
modes andtypes. The two themesare
theonstrution ofabstrat domains formode analysis oftyped logiprograms,
theveriation oflogiprogramsfor non-standardseletionrules.
Modes and types have quite dierent, albeit ertainly related, meanings for the two
themes. Within eah theme, our usage of these notions follows widespread
onven-tions. To avoid onfusion,itseemstherefore reasonableto keep thetwo themeslearly
separated.
This gives riseto thefollowing strutureof this thesis. The thesis has three parts:
an introdutory partand two partsorresponding to thetwo themes. Part Iis divided
into twohapters. Chapter1onsistsoftwoseparate introdutionsforParts IIandIII.
The work presentedin Part IIhasbeenaepted forpresentationat the 9th
Inter-national Workshop on Logi-Based Program Synthesis and Transformation
(LOPSTR'99) [SHK99a ℄. The work presented in Part III is based on three
onfer-ene papers [SHK98, SHK99b, Sma99 ℄, two of whih the author has written together
Abstrat ii
Aknowledgements iii
Prefae iv
I Introdution and Bakground 1
1 Introdution 3
1.1 Mode AnalysisforTyped Logi Programs . . . 3
1.1.1 Previous Work . . . 3
1.1.2 ExploitingType Delarations . . . 6
1.2 Non-StandardDerivations . . . 7
1.2.1 Corretness Properties of Programs . . . 8
1.2.2 TerminationofInput-ConsumingDerivations . . . 9
1.2.3 Ensuring Input-ConsumingDerivations . . . 10
1.2.4 Terminationand blokDelarations . . . 10
1.2.5 FurtherAspets of Veriation . . . 11
1.2.6 Weakening Some Conditions . . . 12
1.2.7 Related Work and Conlusion. . . 12
2 Notions of Modes and Types 13 2.1 Modes . . . 13
2.1.1 Desriptive versusPresriptive Modes . . . 14
2.1.2 The Granularity . . . 16
2.2 Types . . . 17
2.2.1 What is aType? . . . 17
2.2.2 Non-ground Types . . . 19
2.2.3 Polymorphism . . . 19
2.2.4 Desriptive versusPresriptive Types . . . 20
2.3 CombiningModesand Types . . . 21
2.3.1 Diretional Types . . . 21
2.3.2 A Delarative ViewofModes . . . 22
3.1 Introdution. . . 26
3.2 Motivating and IllustrativeExamples. . . 27
3.3 Notation and Terminology . . . 28
3.4 RelationsbetweenTypes. . . 29
3.5 TraversingConrete Terms . . . 33
4 Abstrat Domains for Mode Analysis 40 4.1 Abstration ofTerms . . . 40
4.2 TraversingAbstrat Terms. . . 44
4.3 Abstrat Compilation . . . 46
4.4 Implementationand Results . . . 49
4.5 Disussionand RelatedWork . . . 50
III Non-Standard Derivations 54 5 Corretness Properties of Programs 56 5.1 WhyNon-StandardDerivations? . . . 56
5.2 Notation and Terminology . . . 59
5.3 Modesand Permutations. . . 61
5.3.1 TheOrder oftheAtomsina Query . . . 61
5.3.2 Arethose Permutations Really Neessary?. . . 62
5.3.3 Uniquenessof Derived Permutations . . . 63
5.4 PermutationNielyModedPrograms. . . 65
5.5 PermutationWellModedPrograms. . . 68
5.6 PermutationWellTyped Programs . . . 69
5.7 Type-Consistent Programs. . . 70
6 Termination of Input-Consuming Derivations 72 6.1 Terminationand theSeletion Rule. . . 72
6.2 Existentialvs.UniversalTermination. . . 74
6.3 ControlledCoroutining. . . 74
6.4 Showingthat aPrediate is Atom-Terminating . . . 77
6.5 ApplyingtheMethod . . . 82
6.6 Disussion . . . 83
7 Ensuring Input-Consuming Derivations 84 7.1 The Simpliityof blokDelarations . . . 84
7.2 TerminologyRelatedto blok Delarations . . . 85
7.3 PermutationSimplyTypedPrograms . . . 85
7.4 PermutationRobustlyTypedPrograms . . . 89
8.2 Left-Based Derivations . . . 99
8.3 Terminationand SpeulativeBindings . . . 100
8.3.1 Terminationby notUsingSpeulativeBindings . . . 101
8.3.2 Terminationby notMakingSpeulative Bindings . . . 102
8.4 Terminationand Atom-TerminatingPrediates . . . 105
8.5 Disussion . . . 111
9 Further Aspets of Veriation 112 9.1 UniationFreePrograms . . . 112
9.2 Our-ChekFreedom . . . 115
9.3 Floundering . . . 116
9.4 Errors Relatedto Built-ins . . . 117
9.4.1 The Connetion betweenDelayDelarationsand TypeErrors . . 117
9.4.2 ExploitingConstant Types . . . 118
9.4.3 Atomi Positions . . . 119
9.5 Disussion . . . 120
10Weakening Some Conditions 121 10.1 Simplifyingthe blokDelarations . . . 121
10.1.1 PermutationSimplyTyped ProgramsUsingConstant Types . . 121
10.1.2 Programs thatRespetAtomi Positions . . . 123
10.1.3 ExploitingtheFatthatDerivationsAre Left-Based . . . 124
10.2 Weakening Input-Linearityof ClauseHeads . . . 126
10.3 GeneralisingModes. . . 129
10.4 Disussion . . . 129
11Related Work and Conlusion 131 11.1 RelatedWork . . . 131
11.1.1 The Signianeof \PinningDown theSize" ofan Atom . . . . 131
11.1.2 Guarded HornClauses . . . 132
11.1.3 Coroutining andTerminatingLogi Programs . . . 133
11.1.4 Strong Termination . . . 133
11.1.5 Generating DelayDelarations Automatially . . . 133
11.1.6 Veriation UsingModes and Types . . . 134
11.1.7 TerminationofLD-Derivations . . . 135
11.1.8 TerminationforLoalSeletionRules . . . 135
11.1.9 Diretional Types . . . 135
11.1.10Terminationby ImposingDepthBounds . . . 136
11.1.11Beyond Suess and Failure . . . 136
11.1.12TerminationofWell-ModedPrograms . . . 136
11.1.139-UniversalTermination . . . 136
11.1.14Assertion-Based Debugging of(Constraint)Logi Programs . . . 137
11.2 Conlusion . . . 137
11.2.1 Some Distintive NovelIdeas . . . 137
11.2.2 Open Problems . . . 139
Introdution
Inthishapter,wewillgivetwoseparateintrodutionsforParts IIandIII,respetively.
Asmentionedintheprefae,bothpartsmakeuseofnotionsofmodeandtype,butthey
usethese notions inquitedierent ways.
In Part II, a mode is a haraterisation of the degree of instantiation of a term.
A type is a set of terms dened by means of a delaration, as provided in typed logi
programminglanguages suh asGodel [HL94 ℄or Merury[SHC96℄.
InPartIII,amodeisaspeiationofeahargumentpositionofeahprediateina
programaseitherinputoroutput. Atypeisanysetoftermslosedunderinstantiation.
InChapter2,wewillonsidertherelationshipsbetweenthesenotionsinmoredetail.
1.1 Mode Analysis for Typed Logi Programs
InPartIIweprovideagenerimethodforonstrutingabstratdomainsformode
anal-ysisoftypedlogiprograms. Amodeisaharaterisationofthedegreeofinstantiation
of atermat a ertain pointintheexeution ofa program. Mode analysis isonerned
withndingthemodesofaprogram. Wenowpresentanintrodutiontomodeanalysis
usingabstrat domainsand thenproeedto theatualontributionof PartII.
1.1.1 Previous Work
Thefollowingexampleillustratesthenotionsofdegree of instantiationand point in the
exeution.
Example 1.1 Considerthefollowingprogram 1
fortheappendprediate.
append(Xs,Ys,Zs) :-Xs = [℄, Ys = Zs. append(Xs,Ys,Zs) :-Xs = [X|Xs1℄, Zs = [X|Zs1℄, append(Xs1,Ys,Zs1). 1
append(Xs,Ys,Zs) :-ground(Xs), iff(Ys,Zs). append(Xs,Ys,Zs) :-iff_and(Xs,X,Xs1), iff_and(Zs,X,Zs1), append(Xs1,Ys,Zs1). ground(ground). iff(X,X). iff_and(ground,ground,ground). iff_and(any,ground,any). iff_and(any,any,ground). iff_and(any,any,any).
Figure 1: An abstrationof append
When weassume aninitialqueryappend([1;2℄;[3;4℄;Cs)andthestandardleft-to-right
seletion rule,thenwe an saythat at eah pointin theexeutionjust before an atom
append(s;t;u) is alled, s and t have the following degree of instantiation: they are
ground. Moreover, foreveryomputedanswer,Cs isinstantiatedtoagroundterm. /
Informationasintheaboveexampleanbederivedusingabstratinterpretation[CC77℄.
Herewewilllookatapartiulartehniqueofabstratinterpretationalledabstrat
om-pilation[CD94,CD95 ,DW86,HWD92℄,meaningthatanabstratprogramisevaluated
usinga onretesemantis.
Example 1.2 Corresponding to the program inExample 1.1 is the abstrat program
showninFigure 1. Note thattheabstratprogramis obtainedbyreplaingall
unia-tionsin the onrete program with allsto ground, iff and iff_and. These alls are
alledabstratuniations. Theabstratuniationsoperateonabstrattermsanyand
ground, where ground represents a term that is denitely ground and any represents
anyterm. Forexample, iffand(s;t;u)expressesthat sis agroundtermifand onlyif
tand uarebothgroundterms. Thisreets thatontheonrete level, a listisground
ifand onlyifits headand tailareground.
When we assume an initial all append(ground,ground,_), all alls to appendin
thisabstratprogramwillhavethetermgroundinthersttwoarguments,andtheonly
answer for append is append(ground;ground;ground). It has been shown by Codish
and Demoen [CD95 ℄that from this, itan be onludedthat inthe onreteprogram,
all alls to append have ground terms in the rst two arguments, and all answers to
appendhavegroundtermsinallarguments|justaswasobservedinExample1.1. /
Thetehniqueoftheaboveexamplehasbeendevelopedfurther[CD94 ℄toderive
ground-ness dependenieswithmore detail,usinga more orless ad-honotionof type. Thisis
shown inthefollowingexample. Notethatwe arestillassuminguntyped languages.
Example 1.3 Figure2showsanalternativeabstrationoftheprograminExample1.1.
Without worrying about the details, observe that the abstrat terms used in this
ab-stration would be terms suh as integer, representing an integer, 2
list(integer),
representing a nil-terminated list of integers, list(any), representing a nil-terminated
listwhose elements ouldbearbitrary terms,and any, representinganyterm.
append(Xs,Ys,Zs) :-nil_dep(Xs), iff(Ys,Zs). append(Xs,Ys,Zs) :-ons_dep(Xs,X,Xs1), ons_dep(Zs,X,Zs1), append(Xs1,Ys,Zs1). nil_dep(list(bot)). iff(X,X). ons_dep(list(A),B,list(C)) :-lub(A,B,C). ons_dep(any,_,C) :-C \== list(_). lub(A,A,A). lub(A,A,bot). lub(A,bot,A). lub(any,A,B) :- A \== B.
Figure 2: An alternative abstrationof append
The onrete uniationXs=[XjXs1℄ isabstrated asons_dep(Xs,X,Xs1),whih
relates an abstrat term for the list Xs with the abstrations of its head X and its
tail Xs1. For example, if X is integer and Xs1 is list(integer), then Xs would be
list(integer). If however X is any and Xs1 is list(integer), then Xs would be
list(any).
Forexample,assumeaninitialallappend(list(any),list(any),_),meaningthat
appendisalled withtherst two arguments beinginstantiatedto lists. Thenall alls
to append in this abstrat program will have list(any) in the rst two arguments,
and the only answer for append is append(list(any);list(any);list(any)). For the
onrete program, this implies: if appendis alled with the rst two arguments being
lists,thenall subsequent allsto appendalso have listsintherst two arguments, and
allanswersto appendhave listsinallarguments. Similarly,weouldinfer: ifappendis
alled with therst two arguments being lists of integers, then all subsequent allsto
appendalsohave listsofintegers inthersttwo arguments, and allanswers to append
have listsof integersinall arguments. /
Clearly, in order to abstrat the append program as in the above example, one has
to know what a list is. The denition of a list underlying the above example is the
standardone: foranytype,nilisoftypelist();moreover, ifh isoftype andtis
oftypelist(),thenons(h;t)isoftypelist(). CodishandDemoen[CD94℄arenot
onerned with howsuh denitions ould be derived ingeneral, but onlydeal with a
spei set of typesinludingintegers, lists, dierenelists, and trees, and providethe
denitionsoftheabstrations,suhasthedenitionofons_depintheaboveexample.
1.1.2 ExploitingType Delarations
Intyped logiprogramminglanguages,all typesaredenedbyatypedelaration. For
example, inGodel, thetype oflistsis denedasfollows.
CONSTRUCTOR List/1.
CONSTANT Nil: List(u).
FUNCTION Cons: u * List(u) -> List(u).
The rst line denes a type onstrutor List with one type parameter. We say that
List(u)isapolymorphitype,whereuisatypeparameter. InSetions3.2and3.3,we
explainthesyntaxofGodelinmoredetail,butthisexampleshouldbeself-explanatory.
Throughouttherestofthissetion,wewilluseGodeltypedelarationsto denetypes.
In Part II, we desribea method whihtakesa program,say theappendprogram,
inludingthe type delarations, and generates an abstrat program similarto the one
inExample1.3. Inpartiular,themethodgenerates thedependenyprediatessuhas
ons_dep,whose onstrution seemsquite ad-ho inthework of Codishand Demoen,
sinethey areonsidering untypedlanguages.
To understand why thiswork is a proper generalisation of the work of Codishand
Demoen [CD94 ℄andalso Codishand Lagoon [CL96℄,wemustlookat some more
om-plextypes. Itisnotsurprisingthatwhenone introduesanad-honotionoftypesinto
an untyped programming language, one is unlikely to deal with types that are more
omplex than, essentially, lists and trees. This is dierent when one onsiders typed
languages,aswedo inPartII.
Firstonsiderthefollowingtypedelarations
BASE IntegerList.
CONSTANT Nil: IntegerList.
FUNCTION Cons: Integer * IntegerList -> IntegerList.
These delarations dene the type of integer lists, where we assume that Integer is
the usual built-in type. Note that IntegerList ontains exatly the same terms as
List(Integer),and thereforeitisreasonableto expetthattheabstratdomain
har-aterisingthedegree ofinstantiationofterms oftypeIntegerListshouldbe thesame
astheone skethedinExample1.3. In ourformalism,thisis indeedthe ase.
Ourformalismisbasedonarelationontypesalled\isasubtermtypeof". Integer
andIntegerListarebothsubtermtypesofIntegerList,meaningthatatermoftype
IntegerListan have subterms of type Integer and subtermsof type IntegerList.
If is a subtermtype of ,and is not a subtermtype of , then we say that is a
non-reursive subtermtype of . If is a subterm type of ,and is a subterm type
of , then we say that is a reursive type of . Integer is a non-reursive subterm
type ofIntegerList,and IntegerListisa reursivetype of IntegerList.
The relation\is anon-reursivesubtermtype of" isa generalisation oftherelation
\is a parameter of" whih underlies the domain onstrution of Example 1.3. One
an argue that the type IntegerList hasno raison d'^etre sineit is better to usethe
Example 1.4 Asanotherexample, onsiderafamilytree.
CONSTRUCTOR Family/1.
FUNCTION Person: u * List(Family(u)) -> Family(u).
Foraperson,wemaywant tostorethename,theage,oranyotherattribute. Therst
argument of Person is used for this purpose. Moreover, we want to store the list of
hildrenofthisperson,thatis,alistoffamilytrees,one foreah hild. Asanexample,
onsiderFamily(String). Our formalismonstruts an abstrat domain for this type
whih an haraterise thatall the\names"inthe term
Person("Lisa",[Person("Frank",[℄),Person("Sara",[℄)℄)
areinstantiated,whereasthisis nottruefor theterm
Person("Lisa",[Person(x,[℄),Person(y,[℄)℄):
/
The methods of Codish and Demoen [CD94 ℄ and Codish and Lagoon [CL96 ℄ annot
deal withtheaboveexamples. Wewillsee more examplesinPartII.
Theabstratdomainsusedinourmodeanalysisareentirelyinthespiritofprevious
work [CD94 , CL96℄, and the inherent omplexity of our mode analysis is therefore
similar. In general, the omplexity of a mode analysis depends on the omplexity of
the type delarations. We will argue that the formalismpresented in Part II provides
the highest degree of preision that a generi domain onstrution shouldprovide. It
also helps to understand other, more ad-ho and pragmati domain onstrutions as
instanes of a general theory. One ould always simplify or prune down (widen) the
abstrat domainsforthe sake of eÆieny.
Our method has been implemented in Godel for Godel programs. We show for
some exampleprogramsthat theanalysis times omparewellwitha domainthat only
distinguishesgroundand non-groundterms [CD95℄.
1.2 Non-Standard Derivations
PartIIIisonernedwithveriationmethodsforlogiprogramsthatusenon-standard
derivations, that is, they use a seletion rule other than the usual left-to-right
sele-tion rule of Prolog. We onsider ve aspets of veriation: termination, uniation
freedom 3
, our-hek freedom, ounder freedom, and freedom from errors related to
built-ins.
Non-standard derivationsare usefulfor avarietyof purposes: multiplemodes,
par-allel exeution[AL95 ℄, thetest-and-generate paradigm [Nai92 ℄, and ertain uses of
a-umulators[EG99 ℄.
3
For veriation of logi programs [AE93 , AL95 , BC99 , EBC99℄, in partiular
pro-gramsusingnon-standardderivations, ithasbeenshownto beusefulto assignamode
(inputoroutput)to eahargument positionofeah prediate, andrequireertain
or-retnessproperties onerningthosemodes. We willadoptsome orretness properties
thathave previously ourredinthe literatureandalso introduesome new ones.
Consideringnon-standardderivationsdoesnotimplythatanyatominaqueryanbe
seletedforresolutionatanytime. Forsomeaspetsofveriation,suhastermination
or freedom from errors related to built-ins, it is neessary to ensure a ertain degree
of instantiation of an atom before that atom is seleted [AL95℄. We will argue that
a reasonable minimal assumption is that derivations are input-onsuming, that is, an
atom is onlyseleted one itis suÆientlyinstantiated inits inputarguments, sothat
uniationwitha lauseheaddoesnotinstantiatethese argumentsanyfurther.
Input-onsumingderivationshavenotbeendenedinthisformpreviously,although
the onept is related to (F)GHC [Ued86 ℄ and non-destrutive programs [ER98 ℄. This
isdisussed inSetion11.1.
In existing implementations, input-onsumingderivations an be ensured by delay
delarations [HL94, SIC98, SHC96℄. Using delay delarations, an atom in a query is
seleted only ifits arguments are instantiated to a speieddegree. In partiular, we
willonsiderblokdelarations. Theseareasimplekindofdelaydelarationwhereonly
testsforpartialinstantiation are possible, butnot,forexample, testsforgroundness.
Hene Part IIIofthisthesisis aimedat verifyingprogramswithdelaydelarations,
but we try to take the more abstrat view and formulate results in terms of
input-onsumingderivationswhereverpossible. Thisviewhasnotbeentakenbyotherauthors
previously[AL95 , Lut93, MT95 ,MK97 ,Nai92 ℄.
We now givean overviewof PartIII. Noterst thefollowinggeneral points:
Setion 5.2 denes most of the notation and terminology. Setions 7.2 and 8.2
introduesomefurtherterminologyrelatedto delaydelarations. Inanyase,the
indexan beused to ndthe plaewhere notationorterminology isintrodued.
Setion11.1 isdevotedto the literaturerelatedto PartIII. However, therelated
literature is also onsidered throughout the rest of Part III wherever useful for
motivation orillustration.
1.2.1 Corretness Properties of Programs
InChapter5,weintroduea numberoforretness propertiesonerningthemodesof
a program. The followingexamplegivesa avourof these properties.
Example 1.5 Consider theusualappend=3 program (it willbe given in Figure 10 on
page57), wheretherst two argumentsareinputandthe thirdisoutput. The query
append([1℄;[2℄;Xs);append([3℄;[4℄;Ys); append(Xs;Ys;Zs)
is\well-behaved" inthatit meetsall orretness properties we introdue.
variable has a produer. Moreover, note that Xs and Ys our eah only one in an
output position. In other words, every variable has at most one produer. Finally,
notethatforeahvariable,theoutputourrene preedesanyinputourrene. Ifwe
assumedtheleft-to-right seletionrule,thisouldbeinterpretedasfollows: every piee
of dataisproduedbeforeitis onsumed.
Havingatmostoneprodueristhemainaspetofawell-knownorretnessproperty
alledniely-modedness,andhavingatleastoneprodueristhemainaspetofanequally
well-knownorretness propertyalledwell-modedness. Inontrast, thequery
append([1℄;[2℄;Xs);append([3℄;[4℄;Xs);append(Xs;Ys;Zs)
is notnielymodedbeause there are two output ourrenesof Xs, and it is notwell
modedbeause there isno outputourrene of Ys. /
Asanbeseenintheaboveexample,theorretnesspropertiesaretraditionallydened
assuming that there is a left-to-right data ow in a query (or lause body) [AE93,
AL95 , AM94 , AP94b, BC99 , EBC99 , EG99 ℄: every atom only uses asinputdata that
was produedby other atoms ourring to theleft. With suh a restrited view, it is
not possible to reason about programs where the textual order of atoms diers from
the data ow. We will therefore generalise these properties by onsidering them up
to permutation of a query. Forexample, a query is permutation nielymodedifsome
permutationofit isnielymoded.
1.2.2 Termination of Input-Consuming Derivations
Input-onsuming derivations formalise the natural meaning of input. For most
pro-grams, assuminginput-onsuming derivations is neessary fortermination. For
exam-ple,itiseasy tosee thatgiventheusualappendprogram,an innitederivation forthe
query
append([1℄;[℄;As);append(As;[℄;Bs)
isobtained byalways seletingtherightmost atom (seeFigure 10 onpage 57).
This raisesthequestionwhether assuminginput-onsumingderivationsis suÆient
to ensure termination. In Chapter 6, we dene a lass of prediates for whih this is
indeed the ase. We present a method for showing that a prediate is in this lass.
This methodis based on level mappings,losely followingthe traditionalapproah for
derivationsusingthestandard left-to-right seletionrule[EBC99 ℄.
Note howeverthat thelassofprediates forwhihall input-onsumingderivations
areniteisquite limited. Relyingon thisassumption aloneannotbeaomprehensive
method of showing termination forrealisti programs. This is also the reasonwhywe
1.2.3 Ensuring Input-Consuming Derivations
In Chapter 7, we show how blok delarations, whih are a partiularly simple and
eÆient kind of delay delaration, an be used to ensure that derivations are
input-onsuming. Theblokdelarationsdelarethatertainargumentsofan atommustbe
non-variablebefore thatatom an beseleted forresolution.
Usually,onewouldhave blokdelarationssuhthatanatom isonlyseleted when
its inputpositionsarenon-variable. However, thisissometimesnotsuÆient. Suppose
we have a prediatep=1whose argument is input,and \p(f(1))."is alause dening
thisprediate. The atom p(f(X)) is non-variable in its inputposition. Nevertheless its
seletion would violate the requirement of an input-onsuming derivation, sine
uni-ation with the lause headinstantiates X. This and similar problemsgive rise to the
denitionof two furtherorretness properties for programs. Despite these problems,
blok delarations are adequate for ensuring input-onsuming derivations in existing
implementations.
Previousliteratureon delaydelarationshasnotreognisedthatthesimpliityand
eÆienyofblokdelarationsgivethemaspeialrole. Therehasneverbeena
system-ati aount of when blokdelarationsare suÆient to ensureany desired properties
suh as termination, and when more omplex onstruts, say groundness heks, are
needed.
1.2.4 Termination and blok Delarations
In Chapter 8, we present two approahes to showing orensuring termination for
pro-grams with blok delarations. As suggested above, it is often neessary to make
stronger assumptionsabout the seletion rule rather than just to assume that
deriva-tionsareinput-onsuming. Wedosobyassumingleft-basedderivations. Thisformalises
the\defaultleft-to-right" seletionruleof mostexistingPrologimplementations.
Therstapproahisrelativelysimpleandtriestoeliminatethewell-knownproblem
of speulative output bindings [Nai92 ℄. The approah onsists of two omplementary
methods: one exploits the fat that a program doesnot use any speulative bindings;
theother exploits thefatthata program doesnot make anyspeulativebindings.
The idea of the seond approah is as follows: rst, blok delarations must be
used to ensure that derivations are input-onsuming. Some prediates are known, by
Chapter 6, to terminate for all input-onsuming derivations. For all other prediates,
thetextual positionofatomsusingthose prediates mustbetaken into aount. More
preisely,thelatter atomsmustbe plaedsuÆientlylate, whihensures thatthey are
onlyseleted onetheirinputisompletely instantiated.
Example 1.6 The following lause is part of a program for the well-known n-queens
problem. It isan exampleof thetest-and-generate paradigm.
nqueens(N,Sol)
:-sequene(N,Seq),
A solutionto the n-queens problemis enodedas a permutation of the list [1;:::;n℄,
whihrepresentsthepositionofthequeenineahrowofthehessboard. Theprediate
sequenegeneratesthelist[1;:::;n℄. Thislististhenpermutedusingpermuteandthe
solutionandidatesaretestedforbeinglegalongurationsbytheprediatesafe. The
allto safeours before theall to permute to ahieve oroutining of thetwo atoms
safe(Sol)and permute(Sol,Seq).
In the lause body, the all to permute is plaed suÆiently late. Assuming
left-based derivations, this means that when permute is alled, the input Seq is ground.
With less instantiated input, termination of permute ould not be guaranteed. In
ontrast, the prediate safe will frequently be alled with partially instantiated lists
as input. However, this is not a problem beause, as we will see, the assumption of
input-onsumingderivationsissuÆientto ensureterminationof safe. /
Chapter 8 formalises and extends heuristis that have previously been proposed to
ensure termination of programs with blok delarations under the assumption of a
defaultleft-to-rightseletionrule[Nai92 ℄. Inthisinformalwork,even theseletionrule
itself isnotformalised.
Most approahesto the terminationproblemfor programsusingnon-standard
der-ivations abstrat from the relevane of the textual order of atoms for the seletion
rule. These approahes must either yield relatively weak results, or strengthen the
assumptionsabouttheseletionruleinsomeotherwayratherthanassumingthedefault
left-to-right seletion rule[AL95,Lut93 , MT95 ,MK97 ℄.
1.2.5 Further Aspets of Veriation
In Chapter 9, we study some further aspets of veriation of logi programs using
non-standardderivations.
The rstaspet isfreedomfromuniation. Thismeansthattheuniation
proe-dure an bereplaed with so-alleddouble mathing. Theidea is that when aseleted
atom ina queryisuniedwith theheadofa lause, theinputargumentsof thelause
headarerstboundtotheinputargumentsoftheseletedatom. Thistswiththeidea
that derivations are input-onsuming, sine it means that the inputarguments of the
seleted atom are not instantiated. Afterwards, the output arguments of the seleted
atom areboundto theoutput argumentsof thelause. We willsee thatunder ertain
onditions,programsarefree fromuniation.
Theseondaspetisfreedomfromour-hek. Itiswell-knownthattheuniation
algorithm used in existing logi programming systems leaves out the our-hek for
eÆieny reasons. We show that for programsmeeting ertain orretness onditions,
namely permutation nielymoded, input-linearprograms,theour-hekan safelybe
omitted.
The thirdaspetisfreedomfrom oundering. A derivationounders ifitendswith
a non-empty query where no atom is suÆiently instantiated to be seleted in
aor-dane with the blok delarations. Freedom from oundering is an important aspet
of veriation mainlybeause of its relationshipto termination. In priniple,
means that all derivations would ounder immediately. We show however that under
reasonable assumptions, namely that programs are permutation well typed, no
deriva-tions ounder. This implies that ourmethods for showing terminationin no way rely
on trivialtermination byoundering.
As the lastaspet, we onsider freedomfrom errors relatedto built-ins. These are
typeerrors,arisingfromallslike Xisfoo,orinstantiationerrors,arisingfromallslike
XisV. Onepreviousproposal forpreventing suherrors useswelltyped programsand
delaydelarations to ensurethat built-insare only alled when their inputarguments
are ground [AL95 ℄. Unfortunately, blok delarations annot test (diretly) whether
an argument is ground. The main ontribution of Setion 9.4 is to show that under
ertain onditions,blokdelarationsare nevertheless suÆient. The methodis based
on onstant types, that is types onsisting only of onstants. The most prominent
exampleswouldbeinteger orothernumeritypes. We exploitthefatthatforaterm
of onstant type,beingnon-variableimpliesbeing ground.
1.2.6 Weakening Some Conditions
InChapter10,weonsiderwaysofsimplifyingtheblokdelarationsbyomittingtests
that an be proven at ompile time to be always met at runtime. This is partiularly
usefulforbuilt-ins,sinethereis usuallynodiret way ofhavingdelaydelarationsfor
those. We will also onsiderways of weakening a restrition imposed formanyresults
in Part III, namely that theinputargumentsof eah lause headontains no variable
morethanone. Thisrestritionisquitesevereinthatitpreventstwoinputarguments
beingtestedforequality. Moreover, weonsiderageneralisationofthenotionofamode
ofaprogram,allowingforaprediateto beusedindierentmodeseven withinasingle
exeutionof theprogram.
1.2.7 Related Work and Conlusion
Chapter11takesalookattheliteraturerelatedtoPartIII. Itthendisussessomeideas
and features that are distintive of this work, aswellassome open problems. Finally,
Notions of Modes and Types
This hapter gives an overview of mode and type onepts used in the literature,
en-ompassing the uses made of these onepts in thisthesis. In Setion 2.1, we onsider
modes, in Setion2.2, we onsidertypes, and inSetion2.3, we onsiderways of
om-bining the two onepts. Finally in Setion 2.4, we reall very briey the onepts of
modes andtypesasusedinthisthesis.
2.1 Modes
Oneofthedistintivefeaturesoflogiprogramming,asopposedtootherprogramming
paradigms, is that there is no a priorinotion of inputand output. The same program
an be used to ompute answers to dierent problems [Apt97 ℄. The followingexample
illustratesthis.
Example 2.1 Aprogram like thefollowingisthestandardexampleto introduelogi
programmingto novies [Apt97 ,SS86℄.
diret_flight(rome, london). diret_flight(paris, london). diret_flight(paris, rome). diret_flight(london, bristol). onnetion(X, Y) :-diret_flight(X, Y). onnetion(X, Y) :-diret_flight(X, Z), onnetion(Z, Y).
Thisprogram an beused to answerquestionsof dierent kinds.
Is there aightonnetion from Rome to Bristol?
| ?- onnetion(rome, bristol).
To whih itiesarethere ight onnetions fromRome?
| ?- onnetion(rome, City).
City = london ? ;
City = bristol ? ;
no
From whih itiesarethere ight onnetionsto Rome?
| ?- onnetion(City, rome).
City = paris ? ;
no
Wheredo Ihangeplanesyingfrom Paristo Bristol?
| ?- diret_flight(paris, City), diret_flight(City, bristol).
City = london ? ;
no
Thesedierentways ofusingalogiprogramareusuallyreferredto bysayingthatthe
programisusedindierentmodes. Forexample,onsidertheseondqueryabove. The
rst solutionto thisqueryis omputedbythefollowingderivation:
onnetion(rome;City);diretflight(rome;City);2:
Oneway ofharaterisingthisderivation isbysayingthattherst argument positions
of onnetion and diretflight, respetively, are used as input positions,whereas
theseond positionsareused asoutputpositions.
Another way of haraterising this is by saying that onnetion(rome;City)
and diretflight(rome;City) are all patterns in this derivation, whereas
onnetion(rome;london)and diretflight(rome;london)areanswer patterns. Or
more abstratly, onnetion(ground;free) and diretflight(ground;free) are all
patterns, whereas onnetion(ground;ground) and diretflight(ground;ground)
areanswer patterns.
Forthelastquery,assumingthestandardleft-to-right seletionrule, we might also
saythattherstatomisaproduerofCityandtheseondatomisaonsumerofCity.
Allthose haraterisationssuggest thatmodesare inextriablylinked to the
proe-duralratherthanthedelarativeviewoflogiprogramming. However,itisalsopossible
to take a delarative viewof modes[Nai96 ℄, aswe willdisussinSubsetion2.3.2.
We will now shed some light on dierent notions of modes ourring inthe
litera-ture by omparing them under two riteria. The rst riterion is how presriptive or
desriptive the notion of modes is. The seond riterion is the granularity with whih
modes areharaterised.
2.1.1 Desriptive versus Presriptive Modes
groundnessanalysis modes asveriationtool
modedlanguages
6
?
desriptive presriptive
Figure 3: Desriptive versuspresriptive modes
Groundness analysis
Modeanalysis,moreoftenalledgroundnessanalysis,isonernedwiththequestion\at
agivenprogrampoint,whatisthedegreeofinstantiationofvariablex?",andin
parti-ular,\isxboundtoagroundterm 1
?". Suhinformationisusefulforompiler
optimisa-tionssuhasthespeialisationofuniation,butalsobeauseitimprovesthepreision
of other analyses [MS93 ℄. It is also important for termination analysis [LS96, LS97℄.
Muh researh has been done on groundness analysis [AMSH94 , AMSH98 , BCHK97 ,
Cod97, CBGH97 , CDY94, CD94 , CD95 , CGBH94 , CL96 , GGS99 , HHK97 , HACK00 ,
KSH99, MS93 ,TL97 ℄.
Forthederivationonthefaingpage,itanbeinferredthatatthepointjustbefore
diretflightisalled,therstargument ofdiret flightisa groundterm,andat
thepoint after diretflightis resolved,theseond argument is alsoa ground term.
In this ontext, \mode" is a desriptive onept, that is, no assumptionsare made
about how programs are | or should be | written. The analysis takes an arbitrary
program and desribes themodes of thisprogram. Thisis usuallydone usingabstrat
interpretation [CC77 ℄. Sine groundness is an undeidable property, this desription
an only beapproximate. Forsome program pointsan analysis might be able to infer
thatavariableisboundtoagroundterm, butitannotdeidethegroundnessofevery
variableforevery programpoint.
One usually distinguishesgoal-dependent and goal-independent groundness
analy-ses [CBGH97,CDY94,CGBH94,MS93 ℄. In theformer,one assumesthat theprogram
isexeuted withaninitialgoalthatisinstantiatedtoa ertaindegree. Thisintrodues
a slight presriptive aspet into groundness analysis, sine it assumes that programs
shouldbe usedinaertain way. Mostof theliteratureon groundnessanalysis however
isrelevant forgoal-dependent and goal-independentgroundnessanalysesalike.
Part II is about the onstrution of abstrat domains for groundness analysis. In
theimplementation, these domainsareused forgoal-dependentgroundnessanalysis.
Modes asveriation tool
Modeshave beenused fora varietyof veriation purposes[AM94, EG99 ℄. For
exam-ple, they have been used to show that programs are our-hek free [AL95 , AP94b℄,
uniationfree[AE93 ℄,suessful[BC99℄,andterminating[EBC99 ℄. Hereitisassumed
that eah argument positionof eah prediate is either inputor output, and that the
program and initialgoal fulllertain orretness propertiessuhas being wellmoded
or niely moded. Usually, this approah is not onerned with how these modes are
determined.
For the derivation on page 14, one would say that for both prediates, the rst
argument isinputandtheseondisoutput,whihanbedenotedbywritingthemode
of theprogramasfonnetion(I;O);diretflight(I;O)g.
In thisontext,\mode" isafairlypresriptiveonept, sineassumptionsaremade
about how programs should be written and used. If a program does not adhere to
the orretness property required for a ertain veriation purpose, the veriation
methodisnotappliable. PartIIIof thisthesisuses modesto verifyproperties suhas
terminationand our-hekfreedom.
Moded languages
Themostpresriptiveapproahtomodesistouseamodedlanguage,forexample
Mer-ury[Hen92 ,SHC96 ℄. InMerury,theuserhastodelarethemode ofsomeprediates,
while the mode of others is inferred. The program has to fulll ertain orretness
properties onerningthese modes. Otherwiseit isnotaeptedbytheompiler.
These orretness properties restrit the lass of legal programs and hene to a
ertain extent limit the expressiveness of a language. On the other hand, as Merury
shows,they allow theompilerto generate very eÆient mahineode.
2.1.2 The Granularity
We nowdistinguishdierentmode oneptsbyanotherriterion: thegranularityofthe
formalism to haraterise the instantiation of a term, or in other words, the degree of
preision with whih the instantiation of a term an be haraterised. Note that for
thisriterion,weannot easilydraw apiturelike theoneinFigure3 onthepreeding
page, sinethere is no suh obvious hierarhy. We distinguishbetweentwo-valued and
more ne-grainedharaterisations.
Two-valued haraterisations
Thelowestgranularityisgivenwhenwehaveaharaterisationwhihanonlytaketwo
possible values. Most groundness analyses only distinguish ground and possibly
non-groundterms[AMSH94 ,AMSH98 ,BCHK97 ,CD95 ,HHK97 ,HACK00 ,KSH99 ,MS93℄.
Likewise,theworkswhihusemodesforveriationpurposesonlydistinguishinputand
output positions [AE93 , AL95 , AM94, AP94b, BC99 , EBC99, EG99 ℄. Part III of this
More ne-grained haraterisations
The mode analyses by Codish and others [CD94 , CL96℄ haraterise the degree of
in-stantiation of thelist, say,[1;x;5℄ by theabstrat term list(any),that is, alist whose
elementsannot beharaterised. Note thatharaterising thisdegree ofinstantiation
is only meaningful with some notion of type. Similar approahes have been taken by
Gallagher and de Waal [GW94℄and Van Hentenryk et al. [VCL95 ℄, and in Part II of
thisthesis.
Othermodeanalysesthatprovidearelativelyhighdegreeofgranularitybutwithout
usinganynotionof type have beendevelopedbyJanssensandBruynooghe[JB92℄and
Tan and Lin[TL97 ℄.
ThemodesystemofMeruryisbasedoninstantiationstates,whihareaformalism
for asserting how instantiateda termis. With instantiation states, one ould express,
say, that an argument positionof a prediate is boundto a list of variables when the
prediateisalledandtoagroundlistwhentheprediatesueeds. Thisisarenement
of thenotionofinputand output.
2.2 Types
In logi programming, a type is usually a set of terms assoiated with an argument
position,reetingtheprogrammer'sunderstandingofwhat\kind"oftermisexpeted
inthisargument position. Forexample, as argumentsto theprediatediret flight
we might expetterms suh asromeand paris,butnotthenumber3 orthelist[3;5℄.
Typeshave beenshownto be usefulin all programmingparadigms, sinethey an
help detet logialerrors ina program. However, types arenot as widespreadinlogi
programmingasinimperative andfuntionalprogramming.
As before, we disussdierent notions of types ourringin the literature looking
at them fromvarious angles.
2.2.1 What is a Type?
First,we distinguishvariousapproahesbyhowabstratly and generally thetypesare
desribed. Figure4showsarough subdivisionoftheliteratureinto vegroups. In this
subsetion, weignoretheexisteneofvariables,thatis,weonlyonsidergroundterms.
Built-in types in Prolog
Prologisan untypedprogramminglanguage. Nevertheless,inPrologimplementations,
thereareusuallyafewbuilt-intypessuhasinteger oratom[ISO95 ,SIC98℄. Theseare
onlyof any signianeinonnetion with built-inprediates,forexamplefuntor=3.
Anyall to funtor wherethe thirdargument is a ground termother thanan integer
resultsina type error.
Ad-ho types
pro-built-intypesinProlog ad-ho types regulartypes delared types arbitrarytypes 6 ? onrete, ad-ho abstrat,general
Figure4: Expressiveness,generalityof type formalisms
They suggest that this hoie is for illustrative purposes and that it ould easily be
generalised, but as we will disuss in Setion 4.5, the generalisation is by no means
obvious.
Regular types
Manyauthors have developed formalisms to haraterise types in a more general way,
forexampleregularapproximations[GW94,GL96 ,SG95a℄ortypegraphs[VCL95 ℄. The
work ofCodishand Demoen hasalso beendeveloped furtherinthisrespet[CL96 ℄. In
all of these formalisms, an unlimited number of dierent types an be designed, but
restritionsareimposedwhihensurethat these typesare, insome sense,regular.
Delared types
Typedlogiprogramminglanguages suhasMerury[SHC96 ℄orGodel[HL94℄provide
asyntaxusedtodelare types. Eahonstant,funtionandprediatesymbolusedina
program musthave its type delared. The typedelarationshave to meet a numberof
restritionsthat an be syntatially heked. With these restritionsit is possibleto
type-hek programsat ompiletime. Part IIof thisthesisuses thisnotionof types.
Arbitrary types
The literature that uses types for veriation purposes [AE93 , AL95, AM94, AP94b ,
BC99 , BLR92 ℄ has themost general notionof type: any set of ground terms ould be
2.2.2 Non-ground Types
Intheprevioussubsetion,wedisregardedthepossibilitythatatypemightontain
non-groundterms,orinotherwords,thatanon-groundtermmighthaveatype. Considering
non-ground terms adds another dimension to the lassiation of dierent approahes
to types. Thereforethisaspetshouldbestudied separately.
Intypedlogiprogramminglanguages suhasMerury[SHC96 ℄orGodel[HL94 ℄, a
variablehasatypewhihisinferredfromthedelaredtypesofthesurroundingsymbols.
This ensures that thetype of a termdoesnot hange via furtherinstantiation. Hene
the degree of instantiation and the type of a term are ompletely dierent issues. In
ontrast, Codishand others [CD94 ,CL96℄ woulduse, say, list(any) to represent a list
whoseelementsannotbeharaterised,andthey wouldreferto list(any)asatype. In
Part II, we also introdue objets suh as list(any), but we all them abstrat terms,
nottypes, sinethey onlyharaterise the instantiation ofa term, notits type.
Summarising,intypedlogiprogramminglanguages,anon-groundtermhasatype
whihwillnothangevia furtherinstantiation. Intheterminologyusedbysome works
ongroundnessanalysis,anon-groundtermalsohasatype,butthistyperepresentsthe
degree of instantiation ofa termand henemayhange via furtherinstantiation.
Theliteraturethatusestypesforveriationpurposes[AE93 ,AL95 ,AM94 ,AP94b ,
BC99 ,BLR92 ℄denes atypeasanyset oftermslosedunderinstantiation. Compared
to requiring that a type must be a set of ground terms, this has the advantage that
one an reason about programs that operate on non-ground data strutures. For
ex-ample, the prediate append an be used to appendtwo lists whose elements are not
instantiated. Part IIIalso denes typesinthisway.
Dening atypeasa set ofterms losedunder instantiation linksthenotionof type
to thatof mode. Therefore,we willonsidernon-ground typesfurtherinSetion2.3.
2.2.3 Polymorphism
Perhapsmoreimportantthanthefatthattheprediateappendanbeusedtoappend
two lists whose elements are not instantiated, is the fat that append an be used to
appendtwolistsregardlessofthetypeofthelistelements. Usingaprediateforterms
of dierent types inthisway isalled(parametri) polymorphism.
A polymorphitype is a type that is parametrised by anothertype. For example,
thetype list(integer) is thetype ofinteger listsand isomposedof atype onstrutor
list and a type integer. Foranytype ,there is a type list(). Note thatallowingfor
type-hekingat ompiletime,aspratisedintypedprogramminglanguages,isamuh
harder problemfor polymorphi languages than for monomorphiones [Hen93, Hil93,
Mil78,MO84 ℄.
Part IIof this thesis dealswith groundnessanalysis of polymorphiallytyped
pro-grams. Previous works only allowed for very restrited forms of polymorphism. The
works whih use types for veriation purposes [AE93 , AL95 , AM94 , AP94b , BC99 ,
BLR92 ℄, inludingPart IIIofthisthesis, donottreat polymorphismexpliitly.
type analysis typesasveriation tool
typed languages
6
?
desriptive presriptive
Figure 5: Desriptiveversuspresriptivetypes
to denote the emptylist aswellasthe emptytree. We arenot onerned withad-ho
polymorphismin thisthesis.
2.2.4 Desriptive versus Presriptive Types
As with modes, we an ompare notions of types with respetto how desriptive and
presriptive they are. Figure5 shows a subdivisionof theliteratureinto three groups.
Note that this subdivision is very similar to the one we had for modes (Figure 3 on
page15).
Type analysis
Type analysis [CD94 , CL96, GGS99 , VCL95 ℄ is onerned with the question \what is
thetype of anargument oravariable?". Thisquestionan be qualiedfurtherby
speifyingthetypesoftheargumentsofthequerywithwhihtheprogramisused,
speifyingprogrampointsofinterest,suhastheentryorexitpointofaprediate.
In thisontext, \type" is adesriptiveonept, and typeanalysis isinseparablylinked
to mode analysis. Sayingthatx is boundto alist an be viewed asa statement about
thetype ofx aswellasthedegree of instantiationof x. Typeanalysis isa partiularly
preise kindof mode analysis,asdesribedinSubsetion2.1.1, andfurther inthenext
setion.
Typeanalysisisusuallydoneusingabstratinterpretation[CC77℄. Thepointsmade
aboutabstrat interpretationonpage 15 applyhereaswell.
Types as veriation tool
Justastypeanalysisisapartiularlypreisekindofmodeanalysis,typesasveriation
tool [AE93 , AL95 , AM94 , AP94b , BC99 , BLR92 ℄ an be regarded as a renement of
modes as veriation tool, and have been used for the same purposes. In addition to
assumingthateah argument positionof aprogram iseitherinputoroutput,atype is
type in eah argument position. Usually,thisapproah is not onernedwith howthe
type ofeah argumentpositionisdetermined.
Just likemodesasveriationtool(page 16),\type" isafairlypresriptiveonept
here, sine assumptions are made about how programs should be written and used.
PartIIIof thisthesisuses thisnotionof type.
Typed languages
Aswithmodes,themostpresriptiveapproahtotypesishavingatypedlanguagesuh
as Merury [Hen92, SHC96℄ or Godel [HL94 ℄. Part II dealswith typed languages and
heneusesthispresriptivenotionoftypes. Intypedlanguages,theuserhasto delare
thetypesofeah onstant,funtionand prediatesymbolused. 2
Thetypedelarations
have to meet a numberof restritions thatan be syntatiallyheked. These ensure
at ompile time that no type errors an our. That is, a prediate annot be alled
withan argument nothavingthedelared type.
2.3 Combining Modes and Types
We have seen on page 17 that ne-grained haraterisations of the instantiation of a
termoftenusesomenotionoftype. Ontheotherhand,wehaveseeninSubsetion2.2.2
thatthedegreeofinstantiationofatermplaysaroleinsomeoneptsoftypes. Hene,
modes and types are losely related. We now look at two ways of developing this
relationship.
2.3.1 Diretional Types
A natural wayof joining modes and typesis bythe notionof diretional types [BM95,
BLR92 ,RNP92 ℄. Adiretionaltypeforanargumentofaprediatehastheform !.
It is an assertion that if the argument is instantiated to a degree speied by at
all time, then it will be instantiated to a degree speied by when the prediate
returns. For example, the prediate append in forward mode ould be speied by
append(list!list; list!list; free!list)whihshouldberead as: ifappendisalled
withtherstand seondargumentsbeinglists,thenforanyanswer,allargumentswill
beinstantiatedto lists.
Diretional types have two aspets [BM95℄. One is input-output orretness: if a
allsatisestheinputassertion,thentheanswershouldspeifytheoutputassertion. It
doesnotdependontheseletionrule. Theotherisallorretness: Ifaallsatisesits
inputassertion,alltriggered allsshouldalso satisfytheirinputassertion. Thisaspet
dependson theseletion rule.
Both Part II and Part III of this thesis use formalisms that resemble diretional
types. Theformalismsallowtoexpresstheintuitionthat,say,appendisusedinforward
mode, although the preise meanings of the formalisms dier of ourse. To illustrate
thispoint,wenowshowhow thiswouldbeexpressed. InPartII, simplifyingthesyntax
2
somewhat, this intuition would be expressed by saying that append(list;list;any) is
a all pattern and append(list;list;list) is an answer pattern. In Part III, it would
be expressed by saying that the mode of append is append(I;I;O) and the type is
append(list;list;list).
2.3.2 A Delarative View of Modes
To understand Naish's delarative view of modes [Nai96 ℄, we must rst understand
his notion of type. It often happens that the suess set of a program, that is, the
set of ground atoms that are true in all its models, ontains atoms that are not true
aording to the programmer's intentions. For example, the suess set of the usual
appendprogramontainstheatomappend([℄;7;7). Atypeisasetofatomsspeiedby
the programmer whih exludes suh unintended atoms. For example, a natural type
of appendwouldbe thesetof all groundatoms append(s;t;u) wheres;t;u arelists.
It isdesirablethatanyallto alogiprograman onlygiveanswersthatareinthe
type. Calls that ould result in answers not in the type should be onsidered unsafe.
Supposewe arewondering whether a allto append(s;t;u)is safe. Ifwe knewthat all
ground instanesofappend(s;t;u) thatarein thesuess setof appendarealso inthe
typeofappend,thenwewouldknowthattheallappend(s;t;u)issafe. However, there
isno wayweould know thesuess setwithoutatuallyexeuting theprogram.
Therefore, we have to approximate the suess set. A mode of a program is any
set of ground atoms whih is a superset of the suess set. One mode suggested for
append is fappend(s;t;u) j s 2 list^(t 2 list () u 2 list)g. Consider again the
questionwhetheraallissafe. Iftheallisappend([℄;X;X),thenithasagroundinstane
append([℄;7;7) whih is inthe mode but notin thetype, and it is therefore unsafe. If
theallisappend([℄;X;[℄),thenforallinstanesinthemode,Xmustbeboundtoa list,
and hene all instanes inthe mode arealso in the type and the allis safe. In short,
themode together withthetypeenode therequirement that either theseond orthe
thirdargument must bea listfora allto besafe, whihmeans thateitherthe seond
or the thirdargument must be input. This shows how proedural informationan be
derivedfrom thisdelarative view.
2.4 Summary
In thishapter, we gave an overview of mode and type oneptsused intheliterature,
bylookingat these onepts from dierent angles. We now reall the mostimportant
properties of themode and type oneptsusedinParts IIand III ofthisthesis.
In Part II, modesare
desriptive: themodesofa program areanalysed, notpresribed;
ne-grained: themodesareharaterisedvery preisely.
presriptive: we onsider typed programming languages, where a program must
meet ertain riteria onerningthe types beforeit an be aepted by the
om-piler;
polymorphi: a type an be parametrisedbyanothertype;
independent ofinstantiation: thetypeofatermdoesnothangeviainstantiation.
In Part III,modesare
(relatively) presriptive: the programs must meet ertain riteria onerningthe
modesforour methodsto be appliable;
oarse: itis onlypossibleto delare thatarguments areinputoroutput.
In Part III,typesare
\arbitrary": onthelevelofthetheory,anysetofterms(losedunderinstantiation)
ould be atype;
(relatively) presriptive: the programs must meet ertain riteria onerningthe
typesforourmethodsto be appliable;
losed under instantiation: if a term has a type, then it ontinues to have that
Mode Analysis for Typed Logi
The Struture of Types and
Terms
Thispartofthethesisdesribesamodeanalysisfortypedlogiprogramsusingabstrat
interpretation. Itisdividedinto two hapters. Thishapter isonerned withonrete
terms,whiharethedatausedintheprogramswewanttoanalyse. Wedenerelations
between the types in a program giving rise to ertain strutural properties of terms
whih themode analysis issupposedto haraterise.
In the next hapter, we will thendene abstrat terms to haraterise these
stru-turalproperties, aswellastheatualmode analysis.
3.1 Introdution
Typesareusedinprogrammingtorestrittheunderlyingsyntaxsothatonlymeaningful
expressions areallowed. This enables mosttypographialerrors and inonsisteniesin
the knowledge representation to be deteted by the ompiler. As a onsequene, an
inreasing number of appliations using typed logi programming languages suh as
Merury [SHC96 ℄orGodel[HL94 ℄ arebeing developed.
Modesharaterisethedegreetowhihprogramvariablesareinstantiatedatertain
programpoints. Thisinformationanbeusedtounderpinoptimisationssuhasthe
spe-ialisation of uniationand theremoval of baktraking, and to supportdeterminay
analysis [HK97 ℄. When a mode analysis is formulated interms of abstrat
interpreta-tion, theprogram exeution is traed using desriptions of data (the abstrat domain)
ratherthanatual data,andoperationsonthese desriptionsratherthanoperationson
theatualdata. A simpledomainformode analysishastwoelementsgroundand
non-ground to distinguishbetween ground and possibly non-ground terms. More omplex
domains an haraterise partiallyinstantiateddatastrutures withmore preision.
The mainontribution of thispart of the thesis is to desribe a generi method of
derivingpreiseabstratdomainsformodeanalysisfromthetypedelarationsofatyped
program. Eah abstrat domain is speialised for a partiular type and haraterises
varying degrees of instantiation of terms of this type. In partiular it haraterises
the property of termination. This property is well-known for lists as nil-termination
related to the termination of programs that operate on these terms. For example, if
the prediate Append is alled with the rst argument being a nil-terminated list, all
invoked alls to Append also have the rst argument being a nil-terminated list, and
Appendisguaranteed to terminate.
The proedure for onstruting suh domains is implemented(in Godel) forGodel
programs. Byinorporatingtheonstruteddomainsinto amodeanalyser,weseethat
although thepreision of the analysis is signiantlyimproved, the analysis times (for
the programs tested) ompare wellwith a domain that onlydistinguishesground and
non-groundterms.
The abstrat domains are usedin an abstrat ompilation [CD95 , DW86, HWD92℄
framework: aprogramisabstratedbyreplaingeahuniationwithanabstrat
oun-terpart,andthentheabstratprogramisevaluatedbyapplyingastandardoperational
semantisto it.
We believe that thiswork is thenatural generalisation ofwork by Codishand
oth-ers[CD94,CL96 ℄andtakestheideapresentedthereto itslimits: ourabstratdomains
provide thehighestdegree of preisionthat a generidomain onstrution should
pro-vide. It thus helpsto understand other, more ad-ho and pragmati domain
onstru-tionsasinstanesof a generaltheory.
This hapter is organised as follows. Setion 3.2 introdues three examples.
Se-tion 3.3 denes some syntax. Setion 3.4 denes relations between types. Setion 3.5
denes termination of a term, as well as funtions that extrat ertain subterms of a
term.
3.2 Motivating and Illustrative Examples
We introduethree examples that are used throughout Part II. The syntax is that of
the typed language Godel [HL94 ℄. Variables and (type) parameters begin with lower
ase letters; other alphabeti symbols begin with upper ase letters. We use Integer
(abbreviatedasInt) to illustratea typeontaining onlyonstants(1;2;3:::).
Example 3.1 Thisistheusuallisttype. Wegiveitsdelarationsto illustratethetype
desriptionlanguageof Godel.
CONSTRUCTOR List/1.
CONSTANT Nil: List(u).
FUNCTION Cons: u * List(u) -> List(u).
Listisa(type)onstrutor;uisatypeparameterthatanbeinstantiatedtoanytype
suh as Int or List(Int); Nil is a onstant of type List(u); and Cons is the usual
onstrutor forlistswhose elementsmustall havethe sametype. We usethestandard
listnotation[:::j::: ℄whereonvenient. Itisommonto distinguishnil-terminated lists
from open lists. Forexample, [℄and [1;x;y℄ arenil-terminated,but[1;2jy℄ isopen. /
Example 3.2 Thisexamplewasinventedto ountera ommonpointof ritiismthat
\list attening" annot be realised in Godel, that is terms suh as [1;[2;3℄℄ annot
IMPORT Lists, Integers.
CONSTRUCTOR Nest/1.
FUNCTION E: v -> Nest(v);
N: List(Nest(v)) -> Nest(v).
A trivial nest is onstruted using funtion E, a omplex nest by \nesting" a list of
nestsusing funtionN. The notable propertyof the delaration forN isthat the range
type, Nest(v), is a proper sub\term" (in the syntati sense) of the argument type
List(Nest(v)). We have seen a similar type delaration in Example1.4. We use this
examplethroughouttodemonstratethatthisworkisanon-trivialgeneralisationof
pre-viousapproahesto abstrat domainonstrution [CD94,CL96,TL97℄. TheIntegers
module isimported sinewe frequentlyuseNest(Int) asan example. /
Example 3.3 A table is a data struture ontaining an ordered olletion of nodes,
eah of whih has two omponents, a key (of type String) and a value, of arbitrary
type. We give part of the Tables module whih is provided as a system module in
Godel.
IMPORT Strings.
BASE Balane.
CONSTRUCTOR Table/1.
CONSTANT Null: Table(u);
LH, RH, EQ: Balane.
FUNCTION Node:
Table(u) * String * u * Balane * Table(u) -> Table(u).
Tables is implemented in Godel as an AVL-tree [Emd81 ℄: A non-leaf node has a key
argument,avalueargument,argumentsfortheleftandrightsubtrees,andanargument
whih representsbalaninginformation. /
3.3 Notation and Terminology
ThesetofpolymorphitypesisgivenbythetermstrutureT(
;U)where
isanite
alphabetofonstrutorsymbolswhihinludesatleastonebase(onstrutorofarity
0), and U is a ountably innite set of parameters (type variables). We dene the
order on typesas theorder induedbysome (for examplelexiographial) order on
onstrutorand parametersymbols,whereparametersymbols omebeforeonstrutor
symbols. Parameters are denoted byu;v. A tupleof distint parameters orderedwith
respetto is denotedbyu . Typesaredenoted by;;;;! and tuplesof typesare
denoted by ; .
Let
f
be an alphabet of funtion (term onstrutor) symbols whih inludesat
least one onstant (funtion of arity 0) and let
p
be an alphabet of prediate
sym-bols. Eah symbol in
f
(respetively
p
) has its typeas subsript. If f
h1:::n;i 2 f (respetively p h 1 ::: n i 2 p ) then h 1 ;:::; n i 2 T( ;U) ? and 2 T( ;U)nU. If f h1:::n;i 2 f
, then every parameter ourring in h
1 ;:::;
n
f
h1:::n;i
. A symbol is often written without its type if it is lear from the ontext.
Terms and atoms are dened in the usual way [HL94, HT92 ℄. In this terminology, if
a term has a type , it also has every instane of . 1
Thus in general, the type of a
termisnotunique. Howeverthemostgeneraltypeofa termisuniqueuptoparameter
renaming. If V is a ountably innite setof variables, thenthe tripleL =h
p ;
f ;Vi
denes a polymorphi many-sorted rst order language. Variables are denoted
byx;y; terms by t;r;s; tuples of distint variables byx; y; and a tupleof terms by
t.
The setof variablesinasyntati objeto isdenoted by vars(o).
A substitution (denoted by) is a mapping from variablesto terms whih is the
identityalmost everywhere. The domainof asubstitutionis dom()=fxjx6=xg.
The appliation ofa substitution to aterm tis denoted ast. Type substitutions
aredened analogouslyand denoted by .
Programs are assumed to be in normal form. Thus a literal 2
is an equation of
theform x=y orx =f(y), wheref 2
f
, oran atom Q(y),where Q2
p
. A query
G is a onjuntion of literals. A lause is a formula of the form Q(y) G. If S is a
set of lauses, thenthe tupleP =hL;Si denes a polymorphi many-sorted logi
program.
3.4 Relations between Types
An abstrat term haraterises the struture of a onrete term. It is a ruial hoie
in the design of abstrat domains whih aspets of the onrete struture should be
haraterised[TL97 ,VCL95 ℄. Inthispartofthethesis weshowhow thishoiean be
basednaturallyontheinformationontainedinthetypedelarations. Thisisformalised
inthissetion. We desribe how funtiondelarationsrelatetypes to one another.
Denition 3.1 [subterm type℄ A type is a diret subterm type of (denoted
as /) if there is f h 1 ::: n ;i 2 f
and a type substitution suh that = and
i
= forsome i2f1;:::;ng. The transitive,reexive losureof / isdenoted as /
.
If/
, then isa subterm type of . /
ThroughoutPartII,weimposetworestritionsonthelanguagedelarationsweonsider.
We rst needto denea simple type.
Denition 3.2 [simpletype℄AsimpletypeisatypeoftheformC(u),whereC2
.
/
The restritionsare asfollows:
Simple Range Condition: Forall f
h 1 ::: n ;i 2 f , is asimple type.
Reexive Condition: For all C 2
and types =C(); =C(), if /
,
then isa sub\term"(inthesyntati sense)of .
1
Forexample,thetermNilhastypeList(u),List(Int),List(Nest(Int))et.
2
We do notknowof anyreal programsthatviolatethese onditions. In partiular,they
aremetbyallexamplesinSetion3.2. Wenowmotivatetheneedfortheserestritions.
The SimpleRange Conditionallows for theonstrution of an abstrat domainfor
a type suh asList() to be desribed independentlyof the type . An example of a
violation ofthisonditionwould be to delare
FUNCTION F: String -> List(Float).
in addition to the delarations in Example3.1. Then we would have the pathologial
situation that a term of type List(Float) an have subterms of type String, Float
and List(Float), whereasfor all 6=Float, List() an only have subtermsof type
and List(). InMerury [SHC96℄and intyped funtional languages suh asML or
Haskell [Tho99 ℄, this ondition is enfored by the syntax. For example, the list type
would be delared inHaskellas
data List u = Nil | Cons u (List u)
and addinganotherdelaration suh as
data List Float = F String
would be illegal. Beingable to violatetheSimpleRangeCondition an be regardedas
an artefatof theGodelsyntax.
An exampleof aviolation of theReexive Conditionwouldbeto delare
FUNCTION F: List(List(u)) -> List(u).
in addition to thedelarations in Example 3.1. Then a term of type List(Int) ould
have subterms of type List(Int), List(List(Int)), List(List(List(Int))) et. The
ondition ensures that, for a program and a given query, there are only nitely many
typesand hene, theabstrat program hasonlynitelymanyabstrat domains.
Denition 3.3 [reursivetypeandnon-reursivesubtermtype℄Atypeisareursive
type of (denotedas ./) if/
and/
.
A type is a non-reursive subterm type of (denoted as //) if 6/
and there is a type suh that / and ./ . We write N() = f j //g: If
N()=f 1 ;:::; m g and j j+1
forall j 2f1;:::;m 1g,we abuse notation and
denote thetuple h
1 ;:::;
m
i byN() aswell. /
Notethat forexample,Int./Int,althoughone might nditounterintuitiveto think
of Int as reursive type. Note moreover that in the above denition, ./ inludes
the ase that = . The denition has been designed to ahieve uniformity of the
presentation.
It followsimmediatelyfromthedenitionthat if//,then 6./. The relation /
anbevisualisedasatypegraph(similarlydenedbyJanssensandBruynooghe[JB92 ℄,
Somogyi [Som87 ℄ and Van Hentenryk etal. [VCL95 ℄). The type graph fora type is
a direted graph whose nodesare subtermtypes of . The node isalled the initial
node. Thereisan edgefrom
1 to 2 ifand onlyif 2 / 1
Nest(v)
v
List(u)
u
List(Nest(v))
u
Balance
Table(u)
String
Figure 6: Some typegraphs, withinitialnode highlighted
subtermtypes areall the types not inthe SCC of butsuh that there is an edge
from theSCCto . Thenitenessof thisgraphis ensuredbytheReexive Condition.
Our domainonstrution reliesonthefat thatN() isnite.
Example 3.4 In Figure 6 there is a type graph for eah of the examples in
Se-tion 3.2. Trivially Int ./ Int. However, List(u) ./ List(u) is non-trivial in that,
in the type graph for List(u), there is a path from List(u) to itself. Furthermore
List(Nest(v)) ./ Nest(v). Non-reursive subterm types of simple types are often
pa-rameters, asin N(List(u)) =hui and N(Nest(v)) =hvi. However, thisis notalways
thease, sineN(Table(u))=hu;Balane;Stringi. /
It isimportantthat therelation / is losedunderinstantiationof its arguments.
Lemma 3.1 Let ; be types and a type substitution. If / then / . If
/
then /
.
Proof. For the rst statement, there is f
h1:::n;i 2
f
and a type substitution 0
suh thatforsome i2f1;:::;ng,
i 0 =and 0 =. Consequently i 0 = and 0
= , so / . The seond statement followsfrom therst. 2
The followinglemma statesanotherusefulpropertyof therelations /
and ./.
Lemma 3.2 Let;; betypessothat/
/
and ./. Then ./.
Proof. Sine ./, it follows that / . Thus, sine / , it follows that / . Furthermore / ,and therefore ./. 2
The following lemma ensures that the abstrat domains dened later arewell-dened.
It statesthat anysequeneof non-reursivesubtermtypesterminates.
Lemma 3.3 Let 2 T(
;U) nU and
. Let I be a non-empty index set
(nite or innite)starting at 1 and f(C
i (u i ); i ; i ) ji2 Ig a sequene where C 1 2 , 1 =C 1 (u 1 ) 1 =,dom( 1 )u 1
and,foreah i2I wherei>1:
C i 2 ,dom ( i )u i and C i (u i ) i = i i 1 , 2T( ;U) and //C (u ).
