Linköpings universitet Department of Computer and Information

Science TCSLAB (http://www.ida.liu.se/~tcslab):

Peter Jonsson (4 Ph.D. Students) Jan Małuszyński, Włodek Drabent,

Paweł Pietrzak Ulf Nilsson (1 Ph.D. Student)

TCSLAB: Peter Jonsson Algorithms:

Fast algorithms (theory & practice)

Unusual models: Quantum

computing DNA computing

Complexity:

Temporal & spatial problems

CSP with disjunction

TCSLAB: Ulf Nilsson Modeling and

verification using CLP Local and symbolic

model checking using tabled CLP

Fault isolation in robot control software

Verification of parameterized systems using regular sets

Teaching (C)LP 3rd year Logic

Programming course (LP textbook available free of charge on-line)

PhD courses on Constraint programming (with J.M.)

www.ida.liu.se/~ulfni/teaching.shtml

TCSLAB: Ulf Nilsson

Locating Errors in Constraint Logic Programs

Włodek Drabent, Jan Małuszyński, Paweł Pietrzak

Department of Computer and Information Science

Linköpings universitet{wdr, jmz, pawpi}@ida.liu.se

What…

locating type errors in untyped CLP programs

How…directional types checking verifying the program w.r.t. type specification

Symptoms and errors Symptom: a discrepancy between

user’s expectations and actual program behavior;here: wrong answers or illegal calls

Error: a part of the program responsible for the symptom; here: prefixes of program clauses

The diagnosis problem

Find an error responsible for the symptom

Traditional aprroaches: Testing and tracing Type checking

Problems with the CLP case: Involved control and data flow CLP languages usually untyped

The approach Static analysis computes types T of

predicate arguments on call and on success, e.g.:

Call-type: nqueens(nat, any)nqueens(nat, any)

Success-typeSuccess-type: nqueens(nat, list(nat)): nqueens(nat, list(nat))

Inspection of T by the user results in specification of expected types S .

Automatic error location based on S.

The types

So far in logic programming: (descriptve) types are sets of terms. We extend them to:

describe sets of constrained terms anyfd; handle type parameters e.g. Call-type: append(list(A),list(A),any)

Succ-type: append(list(A),list(A),list(A))

The types (cont’d) New types defined using parametric

regular term grammars by the user, or by the type inference tool

tree(A) -> void; t(A,tree(A),tree(A))

t(2,void,void) is in the type tree(nat) The standard type constructor: list

e.g. list(int), list(anyfd)

The structure of our tool Program

Analyser

Types

Specification editor

User

Types Diagnoser

OKLocalizedWarning

Entry

DiagnosisWorks interactively Initial input:

CLP program Inferred types (Analyser) Diagnosis request (User)

Interactions: Query: intended type (Diagnoser) Answer to the query (User)

Output: incorrect clause and atom

N-queens:-entry nqueens(int,any).nqueens(N,L):- length(L,N), L::1..N,

constrain_queens(L), labeling(L,0,most_constrained,indomain).

constrain_queens([]).constrain_queens([X|Y]):- safe(X,Y,1),

constrain_queens(Y).

safe(_,[],_).safe(X,[Y|T],K):- noattack(X,Y,K),

K1 is K+1, safe(T,Y,K1). % <- bug here

noattack(X,Y,K):- X #\= Y, Y #\= X+K, X #\= Y+K.

The inferred typesCall-Type: nqueens(int, any)

Succ-Type: nqueens(nat, t66)

t66 --> [nat|t49]

t49 --> []

-------------------------

Call-Type: constrain_queens(list(anyfd))

Succ-Type: constrain_queens(t60)

t60 --> []

t60 --> [anyfd|t49]

t49 --> []

…

Diagnosis session

After providing types for:

Call-Type: constrain_queens(list(anyfd))

Call-Type: safe(anyfd, list(anyfd), int)

Succ-Type: safe(anyfd, list(anyfd), int)

Succ-Type: constrain_queens(list(anyfd))

Succ-Type: noattack(anyfd, anyfd, int)

Diagnoser’s warning

…we got a warning

Clause (lines: 15 - 18)

safe(X,[Y|T],K) :- noattack(X,Y,K),

K1 is K+1, safe(T,X,K1).

suspicious.

Cannot prove call to safe(T,X,K1):

T: list(anyfd) X: anyfd K1: int

Features of the diagnoser Static (no execution, no test data) Finds all type errors Minimal specification effort User’s specification is memoized Applicable to not fully developed

programs (with missing fragments)

Demo…

Summary A verification method for

parametric descriptive types. A specification language. A technique for locating type

errors. A type inference technique. A diagnosing tool.