Locating type errors in untyped CLP programs

W lodzimierzDrabent 12

,JanMa luszynski 1

,andPawe lPietrzak 1

1

Linkopingsuniversitet,DepartmentofComputerandInformationScience

S{58183Linkoping,Sweden

email:fwdrjjmzjpawpig@ida.liu.se

2

InstituteofComputerScience,PolishAcademyofSciences,ul.Ordona21,

Pl{01-237Warszawa,Poland

Thischapter presentsastatic diagnosis toolthat locatestypeerrors in un-

typedCLPprogramswithoutexecutingthem.Theexistingprototypeisspe-

cialisedforthe programminglanguageCHIP[4.10], but theideaapplies to

any CLP language.Thetoolworkswith approximated specicationswhich

describe types of procedure calls and successes. The specications are ex-

pressedasacertainkindof termgrammars.Thetoolautomatically locates

at compile time all the errors (with respect to a given specication) in a

program.Thelocatederroneousprogramfragmentsare(prexesof)clauses.

The tool aids the user in constructing specications incrementally; often a

fragment of the specication is already suÆcient to locate an error. The

presentation is informal. The focus is on the motivation of this work and

on thefunctionality of the tool. Some related formal aspects are discussed

in [4.15, 4.29]. Theprototype tool is available from http://www.ida.liu.se/

~pawpi/Diagnoser/diagnoser.html.

4.1 Introduction

Inatraditionalsetting,theprocessoflocatinganerrorstartswithasymptom

observedwhenrunningtheprogramontestinputdata.Asymptomisadis-

crepancybetweensomeuserexpectations andthebehaviouroftheprogram

athand,e.g. awrongcomputed answeroraprocedure callwith arguments

which areoutsidetheintended domainofapplication.After asymptom has

been obtained,onewantsto locatethe error that is aminimalfragmentof

theprogramcausing thesymptom.

A rather ad hoc approach to locating an error is tracing the execution

whichshowsasymptom.Inthecaseofdeclarativelanguages,tracingispar-

ticularly diÆcult because the execution steps are rather complex and not

re ected explicitly in the program. A moresystematic techniquefor locat-

ingerrorsisdeclarativeoralgorithmicdebuggingproposedin [4.31]forlogic

programs (see also [4.18, 4.25]). Declarative diagnosis of CLP programs is

studiedin Chapter5ofthisvolume.



The authors acknowledge the contribution of Marco Comini who was largely

In contrast to the above mentioned approaches, we propose to locate

errorsin a CLP program without searching for symptoms, that is without

executingtheprogram.Theideacanbelinkedtomethodsforprovingpartial

correctnessof a programwith respect to aspecication,such as [4.5,4.12,

4.13,4.14,4.1].Ourtooltriestoconstructaproofthattheprogramiscorrect

w.r.t. the specication. If the proof is obtained then every execution will

be free of symptoms violating the specication. Conversely, if a symptom

violating the specication can be observed, a proof does not exist. In an

incorrectprogram our tool nds all the fragments that are responsible for

nonexistenceoftheproof.Tousethetooltheuserneednotbefamiliarwith

theunderlying programvericationtechniques.

Wewantedto makethe diagnoseraseasy touseaspossible.Toachieve

thisitwasnecessary:

{ tochooseasimplespecicationlanguageeasytounderstandbytheuser,

{ tominimisethespecicationeortnecessarytolocateanerror,

{ toallowdiagnosisofseparatefragmentsofprograms,

{ toprovideaconvenientuserinterface.

We focus onthe questionwhether incorrectprocedure calls and wrong an-

swersmayappearinsomecomputationsofagivenprogram.Thespecication

providedby theuserdescribesasupersetoftheexpectedcalls andasuper-

set of the expected answers in computations of the program. Theprogram

may or may not satisfy these expectations. The above mentioned sets are

describedintermsofparametrictypessuchaslists,trees,etc. Thelanguage

oftypesiseasytounderstandandallowseÆcientcheckingoftheverication

conditions.Ontheother hand,thischoicerestrictstheconsidered errorsto

typeerrors.

WedealwithuntypedCLPlanguagesand,incontrasttoacommonprac-

ticeintypedlanguages,wedonotrequiretypesofprogramconstructstobe

speciedapriori.

Figure4.1presentsageneraloverviewofthetool.Thetwomain compo-

nentsarethetypeanalyserandthediagnoser.

Theanalyserisused toinfertypesofthepredicatesinagivenprogram.

Theroleofthediagnoseristolocatetheerrors.Diagnosismayberequested

iftheinferredtypeofapredicateisdierentfromthatexpectedbytheuser.

The diagnoser responds with a list of types on which the diagnosed type

depends. In order to locate the error, some of the typesin the list (in the

worst case all of them) have to be specied by the user. The list of types

issortedin awaythat aimsat reducingtheamountof interactionwith the

user.

ThespecicationrequestsarerepresentedbythequestionmarkinFig.1.

AnerrorlocatingmessageisgeneratedbythediagnoserassoonasasuÆcient

subsetoftherequiredtypesisspecied.Providingfurther specicationmay

Required Types

TYPE ANALYSER

Inferred Types

Errors DIAGNOSER

?

Program USER

Fig.4.1.Overviewofthetool

Thediagnoserndsincorrectclauses.Evenmore,itlocatesanerrordown

toaclauseprex.It isabletolocatealltheerrorsintheprogram.Inother

words,allthereasonsthattheprogrambehavesincorrectly(withrespectto

thespecication)arewithinthelocatedclauseprexes.Thus,ifnoerrorsare

foundthentheprogramiscorrect.Anobviouslimitationisarestrictedclass

ofspecications.

Theactualdiagnosisisperformedwithoutreferringto anysymptoms.It

refersneither to program execution norto the resultsof program analysis.

Sothediagnoser canwork withouttheanalyser.The role oftheanalysis is

auxiliary. Ithelps to discoverthat theprogram ispossiblyincorrectand to

suggestastartingpoint ofthediagnosis.Theresultsof theanalysis canbe

used asadraftfor thespecication;this simplies thetask of constructing

thespecicationbytheuser.

The rest of this paper is organised as follows. Section 4.2 discusses the

conceptofpartialcorrectnessandthelanguageoftypesasabasisforformu-

lation of thediagnosis problem. Theuse ofthe tool andits functionalityis

illustratedonanexampleinSection 4.3.Section 4.4explainsinformallythe

underlyingprinciplesofstaticdiagnosis,Section 4.5describesthetreatment

ofdelaysinourapproachandSection 4.6discussessomeimplementationis-

sues.Section4.7enumeratessomelimitationsofourapproach.Relatedwork

issurveyedin Section4.8.Section 4.9presentsconclusionsandfuturework.

4.2 The Specication Language

Intuitively,aprogramis correctifforanyinputdataitbehavesasexpected

by the user. For automatic support of (in)correctness analysis we need a

languagefordescribingboththeprogram behaviouranduser expectations.

Computations of CLP programs are quite complex. Therefore we focus on

selectedaspects ofcomputations, namelyoncalls and successesofprogram

predicatesinallcomputations.Thissectionintroducesasimplelanguagefor

describingtheformofpredicatecallsandsuccesses.Theactualbehaviourof

aprogramcanbeapproximatedbyanautomaticallygenerateddescriptionin

thislanguage.Thelanguagewillalsobeusedforapproximatespecications

which describeuser's expectations. Such specicationsare usedby ourtool

forautomaticerrorlocation.

Noticethattheformofprocedurecallsandsuccessesisamongtheprop-

ertiesthatcanbedescribedbyassertionsdiscussedinChapter1.Theprop-

erties wedeal with can beconsidered a special caseof callsand success

assertions,taggedwithtrueorwithcheckdependingonwhether theprop-

erties are obtained from program analysis or are a partof a specication.

Theactualwaysofdescribingsetsofconstrainedatoms,towhichassertions

refer,arehoweverofsecondaryimportanceinChapter1.Hereweintroducea

formalismfordescribingaparticular,suitableforourpurposes,classofsuch

sets.

Beforeintroducingourspecicationlanguagein Section4.2.2,weexplain

howthebehaviourof aCLP programischaracterisedin termsofpredicate

calls andsuccesses.Thisincludes discussing somebasicsof thechosenCLP

semanticsandpresentingaformaldenitionofaprocedurecallandsuccess.

Somereadersmayprefertoskipthelatter.

WeassumeaxedCLPlanguage(objectlanguage)overaxedconstraint

domainD.InthenextsubsectionD isarbitrary,therest ofthepaperdeals

withCLPovernite domains.Tosimplify thepresentation,werstpresent

our approach applied to programs without delays (i.e. executed under the

Prologselectionrule) 1

.TreatmentofdelaysisdiscussedinSection4.5.

4.2.1 Callsand Successesofa CLP Program

InthissectionwepresentthesemanticsofCLPusedinthisworkandintro-

ducethenotionofanapproximatespecication.

Theerrorswewanttolocatedemonstratethemselvesaswrongcomputed

answersor as wrong arguments of predicate calls,where \wrong" refersto

user expectations or to a priori given requirements concerning the use of

built-ins.Theseaspectsofcomputationscanbecapturedbyassociatingwith

1

Weconsiderconstraintsasneverdelayed,assumingthateachconstraintispassed

totheconstraintsolverassoonasitisselectedbythePrologselectionrule.The

each predicate two sets: one of them describing all calls and the other all

successesintheconsideredclassofcomputations.Thissectiondiscussesthis

ideain moredetail.Foramoreformalpresentationsee[4.29].

WeconsiderCLPprogramsexecutedwiththePrologselectionrule(LD-

resolution) and using syntactic unication in the resolution steps. In CLP

withsyntacticunication,function symbolsoccurringoutsideofconstraints

aretreatedasconstructors.So,forinstanceinCLPoverintegers,thegoalp(4)

failswith theprogramfp(2+2) g(but thegoalp(X+Y) succeeds).Terms

4 and 2+2 are treated as not uniable despite having the same numerical

value.Also, aconstraintmaydistinguish such terms. Forexamplein many

constraints ofCHIP,an argumentmaybeanaturalnumber(or a\domain

variable")butnotanarithmeticalexpression.Resolutionbasedonsyntactic

unicationisusedinmanyCLPimplementations,forinstancein CHIPand

inSICStus[4.30].

Computations of a CLP program involve constraints. Therefore, predi-

catecalls and successes takethe form of constrained atoms. A constrained

expression (atom, term, etc) is a pair of the form c[]E where c is a con-

straintandE is anexpression such thateachfreevariableofc occurs inE.

For example, X::1::4[]p(X;Y) is a constrained atom in CHIP notation 2

.

Forac notsatisfyingthe lattercondition,c[]E will be anabbreviationfor

(9

:::

c)[]E wherethequanticationisoverallvariablesnotoccurringin E.A

constrainedexpressiontrue[]t mayberepresentedast.

We are interested in calls and successes of program predicates in com-

putations of the program. Both calls and successes are constrained atoms.

A precise denition is given below taking a natural generalisation of LD-

derivationasamodelofcomputation.

An LD-derivation isasequence G

0

;C

1

;

1

;G

1

;::: of goals,inputclauses

and mgu's (similarly to [4.26]). A goal isof the form c[]A

1

;:::;A

n , where

cisaconstraintandA

1

;::: ;A

n

areatomicformulae(includingatomiccon-

straints). For a goal G

i 1

= c[]A

1

;:::;A

n

, where A

1

is not a constraint,

and a clause C

i

= H B

1

;:::;B

m

, the next goal in the derivation is

G

i

=(c[]B

1

;:::;B

m

;A

2

;:::;A

n )

i

providedthat

i

isanmguofA

1 andH,

cis satisable and G

i 1 and C

i

do nothave commonvariables. IfA

1 is a

constraint then G

i

= c;A

1 []A

2

;:::;A

n (

i

= and C

i

is empty) provided

thatc;A

1

issatisable.

ForagoalG

i 1

asabovewe saythat c[]A

1

isacall (ofthederivation).

ThecallsucceedsintherstgoaloftheformG

k

=c 0

[] (A

2

;:::;A

n

)(where

k>i)of thederivation. So=

i



k

. Thesuccesscorresponding (in the

derivation)tothecallaboveisc 0

[]A

1

.Forexample,X::1::4[]p(X;Y)and

X ::[1;2;4][]p(X;7)isapossiblepairofacallandasuccessforpdenedby

p(X;7) X 6=3.

2

X::1::4andX::[1;2;3;4]aretwoalternativewaysfordescribingX2f1;2;3;4g

Noticethatinthisterminologyconstraintssucceedimmediately.IfAisa

constraintthenthesuccessofcallc[]Aisc;A[]A,providedc;Aissatisable.

Sowedonottreatconstraintsasdelayed;weabstract frominternalactions

oftheconstraintsolver.

Thecall-successsemanticsof aprogramP,forasetofinitial goalsG,is

apair CS(P;G) =(C;S) of sets of constrainedatoms: theset of calls and

theset of successesthat occur in theLD-derivations startingfrom goalsin

G. Weassumewithoutlossofgeneralitythat theinitialgoalsareatomic.

Sothecall-successsemanticsdescribespreciselythecallsandthesuccesses

in the considered class of computations of a given program. The question

is whether this set includes \wrong" elements, unexpected bythe user. To

requireaprecisedescriptionofuserexpectationsisusually notrealistic.On

theotherhand,itmaynotbediÆculttoprovideanapproximatedescription

Spec = (C 0

;S 0

) where C 0

and S 0

are sets of constrained atoms such that

everyexpectedcall isinC 0

andeveryexpectedsuccessisinS 0

. Wesaythat

P withinitialgoalsG ispartially correctw.r.t. SpeciCC 0

andS S 0

.

Wewill usuallyomittheword\partially".

Our tool uses a xed specication language for writing descriptions of

callsandsuccesses.Theprecisionofspecication,andtheerrorswhichcanbe

discoveredarethusapriorirestrictedbythelanguage.Ontheotherhand,the

simplicityof thelanguageallowseÆcientautomaticlocationof errorsif the

programisnotcorrectw.r.t.agivenspecication.Moreover,theintelligibility

ofthelanguagehelpstheuserintakingrightdecisionsduringaninteraction

withthediagnoser.

4.2.2 DescribingSets ofConstrained Atoms

The program errors considered in this work concern discrepancies between

expectedandactualcallsandsuccesses,inotherwords,betweentheintended

andthe actualcall-successsemanticsoftheprogram. Thus, in order tofor-

mulateaprogramspecication(ortopresentresultsofthestaticanalysisto

the user)we need alanguage for describing sets of constrained atoms and

constrained terms. This section presents the specication language used in

ourtool.Inthispresentationwedonotdistinguishbetweenfunctionsymbols

andpredicatesymbols(andbetweentermsandatoms).

For the purposes of program analysis and diagnosis, we need to com-

putecertainoperationsonsets:set intersectionandunion(possiblyapprox-

imated), inclusion and emptiness, and operations of construction and de-

constructionwhich are explained in Section 4.4.2. The expressive powerof

the formalism is limited to facilitate eective and eÆcient computation of

theseoperations.Duetothislimitation,thecall-successsemantics ofaCLP

programisusuallynotexpressibleinthespecicationlanguageandthespec-

ications provided for programs describe approximations of the semantics.

The approximations will be called types following the terminology used in

Our formalism is a generalisation and adaptation to CLP of the ideas

of [4.11]. In particular, we add a possibility to distinguish sets of ground

(constrained)termsfromthosecontainingalsonon-groundterms.

Types will bedenoted by type terms built of type constructors.Nullary

typeconstructorsarecalled typeconstants.

Somestandardtypeconstantsarenat,neg,any andanyfd:

{ natdenotesthesetf0;1;2;:::gofnaturalnumbers,

{ negdenotesthesetf 1; 2;:::gofnegativeintegers,

{ anydenotes thesetof allconstrainedtermswithsatisableconstraints,

{ anyfddenotesthesetofconstrainedtermsoftheformc[]x,whereeitherx

isavariableandcisaconstraintdescribinganitesetofnaturalnumbers,

orx isanaturalnumber.(Rememberthat wedonotdistinguishbetween

true[]xandx).ThistyperepresentsdomainvariablesofCLP(FD)together

withtheirinstances.

Theremainingtypesaredenedbygrammaticalrules.Forexample,the

rules

p!0

p!s(p)

meanthatthetypeconstantpdenotesthesetoftermsf0;s(0);s(s(0));:::g.

Themeaning of pis formallydened astheset of all termsnot containing

typesymbolsthatcanbederivedfrompbyapplyingthegrammaticalrules.

Foraprecisedenitionthereaderisreferredto [4.17].

Typeintofintegernumbersmaybeexpressedasunionofnegandnat:

int!neg

int!nat

Parametricruleswithnon-groundtypetermsarealsoallowed.Toapplysuch

arule,onehastosubstitutegroundtypetermsfortypevariables.Forexam-

ple,listsaredenedbythefollowingparametricrules:

list()![]

list()![jlist()]

Substituting int forgivesgrammaticalrulesdening thetypelist(int),of

integerlists.Substitutinganyfd forgivesrulesdeningthetypelist(anyfd)

of lists with elements whose type is anyfd. The following example shows

such a list and illustrates how grammar rules are applied to constrained

terms. From list(anyfd)one can derive [anyfdjlist(anyfd) ] by applying the

second rule once. According to the former denition, from the standard

symbol anyfd one can derive, for instance, X2f1;5;7g[]X. Hence from

[anyfdjlist(anyfd)] one can obtain X2f1;5;7g[][Xjlist(anyfd) ] and, in fur-

thervesteps,X2f1;5;7g;Y2f2::6g[][X;3;Y].Thelatterconstrainedterm

belongstotypelist(anyfd),asithasbeengeneratedfromlist(anyfd)anddoes

More precisely, agrammaticalrule dening an n-ary type constructor t

(n>0) isanexpression oftheform:

t(

1

;:::;

n

)!f(

1

;:::;

k )

where 

1

;:::;

n

are distinct type variables, f is astandard typeconstant

(k=0)orf isafunctionsymboloftheobjectlanguage(k>0),andeach

i

(16i6k)is:

{ atypeconstantor

{ atypevariablefromthesetf

1

;:::;

n g,or

{ typetermsoftheformt

i (

i1

;:::;

il

),wheret

i

isal-arytypeconstructor

andf

i1

;:::;

il gf

1

;:::;

n g.

3

Inaddition, it is requiredthat nofunction symbol is aprincipal symbolof

twodistinct grammar rules dening the same type constructor. Here by a

principalsymbolofarulewemeansuchf that:::[]f(:::)canbegenerated

fromtherighthandsideoftherule.Aniteset ofgrammarrulessatisfying

thelatterconditionwillbecalled a(parametric)term grammar.

4

Thetypesarecommunicatedbetweentheuserandthetoolintheformof

typeterms.Theyreferto axedlibraryofgrammarrulesandto additional

rules declared by the user. These rules describe, respectively, the standard

typesof thetooland thetypes theuserexpectsto beuseful. The analyser

generatesnewrules,ifthepresentonesareinsuÆcienttodescribetheresults

oftheanalysis.

In our approach, the call-success semantics of the program is approxi-

mated by providing for each predicate acall type and asuccess type; they

aresupersetsof,respectively,thesetof callsandtheset ofsuccessesofthis

predicate.

4.3 An Example Diagnosis Session

This section gives an informal introduction to our diagnosis technique by

demonstratingtheuseofourdiagnoseronanexample.

TheinputofourtoolisaCHIPprogramaugmentedwithanentrydecla-

rationspecifyingaclassofinitialgoals.Theresultofaninteractivediagnosis

sessionisaspecicationdescribingtheintendedtypesofprogrampredicates

anderrormessageslocatingclausesresponsible forincorrectnessof thepro-

gramw.r.t.thisspecication.

3

Thisrestrictionontheformof

i

isaddedfortechnicalreasons.Itimplies,infor-

mallyspeaking,thatnotypeisdenedintermsofaninnitesetoftypes.Fora

moregeneralformofthisconditionsee[4.17].Similarrestrictionsappearinother

approachestotypeanalysis(e.g.[4.11],therestriction formulatedinformally).

4

This extendsa traditional notion of regular termgrammar, seee.g. [4.11], by