Polymorphic

Types

in

Higher-Order

Logic

Programming

Weidong

Chen

Computer

Science

and

Engineering

Southern

Methodist

University

Dallas

Texas

U.S.A.

wchen@seas.smu.edu

Michael

Kifery

Department

of

Computer

Science

SUNY

at

Stony

Brook

Stony

Brook

NY

U.S.A.

kifer@cs.sunysb.edu

phone

fax

December

Technical

Report

December

Department

of

Computer

Science

SUNY

at

Stony

Brook

Abstract

This

paper

analyses

the

requirements

to

the

notion

of

type

correctness

in

logic

programming

and

proposes

several

adequacy

criteria

for

such

a

system

We

then

present

a

type

theory

for

a

higher-order

logic

programming

language

HiLog

-LSB-

-RSB-

which

is

adequate

in

that

sense

The

proposed

type

system

not

only

captures

type

errors

of

syntactic

origin

but

also

ensures

that

all

atoms

true

in

a

canonical

model

-LRB-

such

as

the

perfect

model

or

the

well-founded

partial

model

-RRB-

of

a

well-typed

program

are

well-typed

Furthermore

type

dependencies

among

arguments

of

functions

and/or

predicates

are

incorporated

into

the

definition

of

welltyped

terms

and

atoms

so

that

the

benefits

of

both

parametric

and

inclusion

polymorphism

are

preserved

Finally

types

are

treated

as

first-class

objects

and

type

declarations

can

be

queried

directly

by

users

making

it

a

suitable

framework

for

schema

integration

of

heterogeneous

databases

Work

supported

in

part

by

the

NSF

grant

yWork

supported

in

part

by

the

NSF

grant

Introduction

Logic

programming

is

derived

from

an

essentially

untyped

framework

namely

predicate

calculus

Any

ground

atom

no

matter

how

ill-typed

it

is

in

the

intuitive

sense

-LRB-

e.g.

a

predicate

person

applied

to

a

city

-RRB-

can

be

legitimately

assigned

a

truth

value

in

a

Herbrand

model

This

raises

a

fundamental

question

of

which

logic

programs

are

to

be

considered

well-typed

The

theory

of

types

in

logic

programming

has

been

an

active

area

of

research

for

a

decade

now

Stimulated

by

the

pioneering

work

of

Bruynooghe

-LSB-

-RSB-

Mycroft

and

O'Keefe

-LSB-

-RSB-

and

Mishra

-LSB-

-RSB-

a

number

of

researchers

extended

these

approaches

to

handle

more

general

classes

of

logic

programs

and

type

systems

These

works

generally

fall

into

two

categories

those

extending

the

prescriptive

theory

of

Mycroft

and

O'Keefe

-LRB-

e.g.

-LSB-

-RSB-

-RRB-

and

those

inspired

by

the

descriptive

type

inference

system

of

Mishra

-LSB-

-RSB-

In

the

prescriptive

approach

Mycroft

and

O'Keefe

-LSB-

-RSB-

adopted

Milner

's

slogan

that

welltyped

programs

do

not

go

wrong

meaning

that

if

a

logic

program

and

a

query

is

well-typed

then

any

SLD-derivation

of

the

query

with

respect

to

the

program

will

remain

well-typed

This

however

bases

a

theory

of

types

upon

a

particular

operational

strategy

and

thus

compromises

the

declarative

semantics

of

logic

programs

In

the

descriptive

approach

Mishra

-LSB-

-RSB-

proposed

a

principle

for

type

inference

of

logic

programs

by

which

types

of

predicates

must

cover

the

denotations

of

the

predicates

in

the

canonic

models

of

logic

program

This

principle

has

been

generalized

by

Yardeni

et

al

-LSB-

-RSB-

for

type

checking

in

the

sense

that

the

denotations

of

predicates

should

be

covered

by

type

declarations

of

predicates

The

purely

model-theoretic

approach

can

not

account

for

type

errors

of

syntactic

origin

For

instance

if

a

predicate

p

is

supposed

to

take

arguments

of

type

string

only

then

the

rule

p

-LRB-

-RRB-

false

would

be

considered

type-correct

because

the

offending

atom

p

-LRB-

-RRB-

is

never

derived

Besides

the

very

notion

of

well-typed

logic

programs

there

is

also

an

important

question

how

expressive

type

systems

need

to

be

Extensions

of

the

type

system

of

Mycroft-O'Keefe

-LSB-

-RSB-

have

been

proposed

to

support

both

parametric

and

inclusion

polymorphism

These

approaches

tend

to

be

too

lax

in

enforcing

parametric

polymorphism

Consider

a

standard

polymorphic

type

specification

for

append

as

an

example

append

-LRB-

list

-LRB-

-RRB-

list

-LRB-

-RRB-

list

-LRB-

-RRB-

-RRB-

bool

-RRB-

-LRB-

-RRB-

This

is

usually

read

as

a

statement

that

all

three

arguments

of

append

must

be

lists

of

exactly

the

same

type

The

question

arises

as

to

the

quantification

of

the

variable

in

-LRB-

-RRB-

One

formal

way

of

reading

this

statement

is

For

every

type

the

function

append

must

belong

to

the

functional

type

list

-LRB-

-RRB-

list

-LRB-

-RRB-

list

-LRB-

-RRB-

-RRB-

bool

-LRB-

where

a

function

belongs

to

such

a

type

if

and

only

if

whenever

it

gets

three

arguments

of

type

list

-LRB-

-RRB-

its

result

is

an

element

of

type

bool

-RRB-

Clearly

such

reading

suggests

universal

quantification

which

turns

out

to

work

as

expected

where

types

are

not

organized

in

a

hierarchy

Unfortunately

with

type

hierarchies

the

inclusion

polymorphism

frustrates

the

whole

plot

For

instance

let

integer

be

a

subtype

of

number

Then

letting

an

atom

such

as

append

-LRB-

-LSB-

X

-RSB-

-LSB-

X

-RSB-

-LSB-

-RSB-

-RRB-

evaluate

to

false

still

leaves

append

in

conformance

with

the

type

specification

-LRB-

-RRB-

-LRB-

as

interpreted

above

-RRB-

Intuitively

however

the

above

atom

should

be

viewed

as

ill-typed

because

its

arguments

are

not

of

exactly

the

same

type

the

last

argument

is

a

list

of

integers

while

the

first

two

are

lists

of

numbers

-LRB-

or

may

be

even

more

general

lists

if

X

is

bound

to

say

a

string

-RRB-

Thus

in

the

extreme

case

when

a

type

system

has

the

largest

type

all

viewing

-LRB-

-RRB-

as

a

universally

quantified

statement

leads

to

a

complete

collapse

of

parametric

polymorphism

To

repair

this

problem

Reddy

-LSB-

-RSB-

proposed

a

device

called

implication

types

Unfortunately

implication

types

are

not

easy

to

use

and

lead

to

complicated

type

specifications

Later

Kifer

and

Wu

-LSB-

-RSB-

introduced

the

notion

of

type

dependency

-LRB-

abbr

TD

-RRB-

and

showed

that

to

get

the

desired

behavior

the

universal

quantification

in

-LRB-

-RRB-

must

be

augmented

with

type

dependencies

of

the

form

and

The

first

dependency

here

states

that

for

each

whenever

the

first

two

arguments

of

append

are

of

type

list

-LRB-

-RRB-

then

so

must

be

the

third

one

Likewise

the

second

dependency

says

that

for

every

if

the

third

argument

has

the

type

list

-LRB-

-RRB-

then

so

must

be

the

first

two

Clearly

the

aforesaid

atom

append

-LRB-

-LSB-

X

-RSB-

-LSB-

X

-RSB-

-LSB-

-RSB-

-RRB-

does

not

satisfy

the

second

type

dependency

While

adopting

the

basic

idea

of

type

dependencies

in

the

present

work

we

show

that

the

notion

introduced

in

-LSB-

-RSB-

is

confusing

two

separate

issues

functional

types

and

argument

constraints

Even

though

the

formalism

of

-LSB-

-RSB-

is

adequate

for

specifying

types

for

predicates

it

leaves

function

symbols

completely

unchecked

The

role

of

types

has

been

traditionally

restricted

to

compile

time

type

checking

in

imperative

and

functional

languages

While

compile

time

type

checking

remains

an

important

objective

types

are

increasingly

being

used

at

run

time

to

provide

inclusion

polymorphism

in

logic

programming

-LSB-

-RSB-

to

support

unification

as

in

Prolog

-LSB-

-RSB-

to

express

applications

that

defy

the

typical

rigid

structure

of

types

-LSB-

-RSB-

and

to

allow

dynamic

bindings

in

object-oriented

programming

-LSB-

-RSB-

In

database

applications

type

information

in

the

form

of

database

schema

can

themselves

be

queried

by

users

or

by

mediators

in

the

integration

of

heterogeneous

database

systems

Typed

predicate

calculus

-LCB-

the

logic

of

-LSB-

-RSB-

-LCB-

has

the

ability

of

a

program

to

reflect

upon

its

own

typing

which

is

useful

for

declarative

debugging

and

for

browsing

schema

declarations

in

knowledge

bases

One

of

the

conclusions

in

-LSB-

-RSB-

was

that

neither

model-theoretic

approaches

-LRB-

such

as

-LSB-

-RSB-

itself

-RRB-

nor

syntactic

approaches

-LRB-

such

as

-LSB-

-RSB-

-RRB-

can

adequately

capture

the

intuition

behind

the

notion

of

type-correctness

in

logic

programming

Worse

yet

the

desired

behavior

to

be

expected

of

this

notion

was

never

clearly

spelled

out

Below

we

list

a

number

of

adequacy

requirements

to

the

notion

of

type

correctness

that

we

deem

to

be

important

in

the

logic

programming

framework

The

first

four

are

dealing

with

definitional

requirements

of

well-typedness

The

last

two

are

concerned

with

the

expressive

power

desired

of

a

type

system

Semantic

adequacy

All

ground

atoms

implied

by

the

program

must

conform

to

all

type

constraints

specified

for

the

respective

predicate

symbols

The

original

system

of

MycroftO'Keefe

-LSB-

-RSB-

does

not

have

this

property

-LRB-

see

-LSB-

-RSB-

-RRB-

although

its

subsequent

reconstruction

on

the

basis

of

sorted

predicate

calculus

-LSB-

-RSB-

is

sound

in

the

above

sense

Syntactic

adequacy

The

type

of

every

non-logical

parameter

should

fit

all

syntactic

contexts

in

which

this

parameter

occurs

For

instance

if

p

expects

a

string-argument

then

say

p

-LRB-

-RRB-

should

not

occur

anywhere

in

the

program

even

if

p

-LRB-

-RRB-

can

not

be

derived

by

that

program

As

noted

above

typed

predicate

calculus

of

-LSB-

-RSB-

fails

this

criterion

Syntactic

non-emptiness

It

should

be

possible

to

assign

each

variable

a

non-empty

type

that

fits

all

syntactic

contexts

in

which

this

variable

occurs

Pure

model-theoretic

approaches

such

as

-LSB-

-RSB-

tend

not

to

have

this

property

Robustness

with

respect

to

subtyping

As

noted

earlier

virtually

every

polymorphic

system

proposed

for

type

checking

with

the

notable

exception

of

-LSB-

-RSB-

collapses

when

inclusion

and

parametric

polymorphisms

interact

Type

reflexivity

It

should

be

possible

to

inspect

-LRB-

reflect

upon

-RRB-

types

using

the

same

logical

language

As

far

as

we

know

only

-LSB-

-RSB-

have

this

property

Dynamic

types

Some

applications

-LRB-

e.g.

object-oriented

knowledge

base

systems

-LSB-

-RSB-

-RRB-

lead

to

types

whose

contents

may

depend

on

the

object-level

data

Again

to

the

best

of

our

knowledge

only

-LSB-

-RSB-

are

sufficiently

flexible

to

support

this

It

should

be

noted

that

type

systems

that

possess

some

of

these

properties

-LRB-

such

as

semantic

adequacy

and

dynamic

types

-RRB-

are

likely

to

render

type-correctness

an

undecidable

notion

-LSB-

-RSB-

However

the

above

list

is

important

as

an

ideal

to

look

up

to

For

certain

classes

of

type

systems

this

notion

may

be

decidable

and

sufficiently

general

tests

for

type-correctness

can

be

devised

for

many

other

classes

-LSB-

-RSB-

This

paper

presents

a

theory

of

types

and

polymorphism

for

a

higher-order

logic

programming

language

HiLog

-LSB-

-RSB-

which

satisfies

all

of

the

above

criteria

In

this

approach

type

declarations

are

formulas

in

HiLog

which

act

as

integrity

constraints

on

HiLog

programs

HiLog

has

been

used

in

the

past

to

specify

types

-LSB-

-RSB-

However

a

different

type

system

was

used

one

that

does

not

satisfy

many

of

the

requirements

above

-LRB-

notably

robustness

of

polymorphism

-RRB-

and

typing

was

specified

only

for

Prolog

programs

a

first-order

subset

of

HiLog

As

far

as

we

know

Prolog

-LSB-

-RSB-

and

-LSB-

-RSB-

are

the

only

other

works

that

describe

a

polymorphic

type

system

for

higher-order

logic

programs

However

Prolog

-LSB-

-RSB-

does

not

incorporate

inclusion

polymorphism

The

language

in

-LSB-

-RSB-

is

essentially

the

second-order

predicate

calculus

with

nonstandard

semantics

described

in

-LSB-

Section

-RSB-

The

language

is

a

subset

of

HiLog

and

its

type

system

supports

neither

inclusion

polymorphism

nor

type-reflection

A

sketch

in

-LSB-

-RSB-

aimed

at

incorporating

inclusion

polymorphism

leads

to

a

non-robust

-LRB-

with

respect

to

subtyping

-RRB-

type

system

This

paper

is

organized

as

follows

Section

briefly

sketches

HiLog

-LSB-

-RSB-

Section

introduces

the

notions

of

type

dependency

and

argument

constraint

Section

presents

axioms

for

special

non-logical

parameters

used

in

specifying

our

type

system

Section

develops

the

notion

of

type-correctness

first

for

Horn

programs

in

Section

and

then

in

Section

extends

this

concept

to

programs

with

negation

-LCB-

an

issue

that

did

not

get

due

attention

in

the

literature

on

types

in

logic

programming

Section

concludes

the

paper

Overview

of

HiLog

We

assume

some

familiarity

with

HiLog

-LSB-

-RSB-

as

it

is

reasonably

well-known

by

now

and

has

been

used

in

a

number

of

projects

-LSB-

-RSB-

Nevertheless

we

briefly

sketch

the

syntax

and

efficient

implementation

of

HiLog

on

top

of

the

XSB

deductive

database

system

is

available

via

anonymous

FTP

to

cs.sunysb.edu

-LRB-

pub/XSB

-RRB-

semantics

of

HiLog

to

make

the

paper

more

self-contained

HiLog

allows

arbitrary

terms

to

appear

in

contexts

where

only

predicates

and

functions

can

occur

in

predicate

calculus

It

treats

predicates

and

functions

as

first-class

entities

and

yet

maintains

the

simplicity

characteristic

of

predicate

calculus

The

language

alphabet

in

HiLog

consists

of

a

countably

infinite

set

of

variables

V

and

a

countable

set

of

intensional

parameters

S

disjoint

from

V

The

set

of

terms

is

the

smallest

set

containing

variables

the

intensional

parameters

and

is

closed

under

term

application

t

-LRB-

tn

-RRB-

where

t

tn

-LRB-

n

-RRB-

are

terms

For

instance

X

-LRB-

a

-RRB-

-LRB-

b

X

b

-LRB-

X

-RRB-

-LRB-

d

-RRB-

-RRB-

is

a

legal

HiLog

term

Note

how

b

and

X

are

used

in

different

roles

here

as

individual

objects

and

as

higher-order

functions

Atomic

formulas

in

HiLog

are

just

the

same

as

HiLog

terms

Complex

formulas

are

constructed

out

of

the

atomic

ones

using

connectives

and

quantifiers

in

the

standard

manner

The

following

for

instance

is

legitimate

in

HiLog

call

-LRB-

X

-RRB-

X

closure

-LRB-

R

-RRB-

-LRB-

X

Y

-RRB-

R

-LRB-

X

Y

-RRB-

closure

-LRB-

R

-RRB-

-LRB-

X

Y

-RRB-

R

-LRB-

X

Z

-RRB-

closure

-LRB-

R

-RRB-

-LRB-

Z

Y

-RRB-

The

first

clause

here

defines

the

familiar

Prolog

meta-predicate

call

The

other

two

rules

define

a

parametric

predicate

closure

-LRB-

R

-RRB-

which

given

a

binary

relation

r

computes

its

transitive

closure

relation

under

the

name

closure

-LRB-

r

-RRB-

The

semantics

of

HiLog

captures

different

roles

an

object

may

play

in

different

contexts

A

semantic

structure

M

is

a

quadruple

hU

Utrue

F

Ii

where

ffl

U

is

a

nonempty

set

called

the

domain

of

M

ffl

Utrue

U

the

domain

of

intensional

parameters

that

represent

true

statements

ffl

I

associates

with

each

intensional

parameter

a

an

element

in

U

ffl

F

associates

with

each

d

U

and

each

k

a

k-ary

function

Uk

U

denoted

by

d

-LRB-

k

-RRB-

F

Let

be

a

variable

assignment

that

associates

with

each

variable

X

an

element

-LRB-

X

-RRB-

in

U

It

is

extended

to

all

terms

as

follows

ffl

-LRB-

s

-RRB-

I

-LRB-

s

-RRB-

for

every

s

S

and

ffl

-LRB-

t

-LRB-

tn

-RRB-

-RRB-

-LRB-

t

-RRB-

nF

-LRB-

-LRB-

-RRB-

-LRB-

tn

-RRB-

-RRB-

Let

A

be

an

atomic

formula

Then

M

j

A

holds

precisely

when

-LRB-

A

-RRB-

Utrue

Satisfaction

of

composite

formulas

is

defined

as

usual

in

predicate

calculus

Interpreted

symbols

such

as

can

be

incorporated

by

requiring

interpretations

to

satisfy

the

following

restrictions

ffl

I

-LRB-

=-RRB-

-LRB-

k

-RRB-

F

-LRB-

-RRB-

Utrue

if

and

only

if

Typed

Logic

Programming

In

-LSB-

-RSB-

parametric

ordered

sorts

were

used

to

define

a

type

system

that

supports

parametric

and

inclusion

polymorphism

However

sorts

alone

have

only

a

limited

utility

as

far

as

type

systems

are

concerned

In

particular

parametric

polymorphism

collapses

in

the

presence

of

subtyping

as

discussed

in

Section

Other

limitations

are

the

lack

of

support

for

dynamic

types

and

type-reflection

To

build

a

type

system

with

desired

functionality

we

follow

-LSB-

-RSB-

and

construct

a

reflexive

type

system

-LCB-

one

in

which

types

are

treated

as

first-order

entities

by

the

logic

For

logic

programming

purposes

we

restrict

our

attention

to

formulas

in

clausal

form

A

program

clause

is

a

statement

of

the

form

A

Ln

where

n

A

is

an

atomic

formula

called

the

head

of

the

clause

and

Ln

are

literals

-LRB-

atoms

or

negated

atoms

-RRB-

forming

the

body

of

the

clause

When

n

the

clause

is

written

as

A

and

is

called

a

fact

As

usual

all

variables

in

a

program

clause

are

implicitly

universally

quantified

and

we

will

also

stick

to

the

convention

that

variables

begin

with

upper-case

letters

while

intensional

parameters

begin

with

lower-case

letters

A

program

is

a

finite

set

of

program

clauses

A

query

clause

is

a

clause

with

no

literal

in

the

head

Such

clauses

will

be

written

in

the

following

form

Ln

where

n

In

the

sequel

program

clauses

will

usually

be

called

rules

or

just

clauses

while

query

clauses

will

go

under

the

name

queries

We

introduce

the

notion

of

type

correctness

in

two

steps

The

next

two

subsections

motivate

and

then

define

the

notions

of

type

dependencies

and

argument

constraints

In

Section

we

define

type

correctness

for

Horn

programs

This

is

followed

by

a

treatment

of

programs

with

negation

in

Section

Along

the

way

we

show

that

the

resulting

notion

satisfies

the

criteria

put

forth

in

Section

Preliminaries

One

of

the

adequacy

requirements

in

Section

was

that

the

type

system

should

be

reflexive

i.e.

that

it

should

be

possible

to

reason

about

types

in

the

object

language

of

the

logic

There

are

several

ways

to

achieve

this

One

is

to

reify

types

i.e.

to

use

regular

first-order

terms

to

denote

types

-LRB-

see

e.g.

-LSB-

-RSB-

-RRB-

We

then

need

a

way

to

specify

the

relationship

between

type

names

and

object-level

entities

and

between

the

types

themselves

which

can

be

done

as

in

-LSB-

-RSB-

The

declaration

of

types

for

intensional

parameters

the

instance-of

relationship

is

specified

using

the

intensional

parameter

The

symbol

will

be

used

to

represent

the

nonstrict

subtype

relationship

HiLog-wise

these

are

merely

intensional

parameters

in

S

which

will

be

given

special

meaning

as

binary

predicates

and

which

will

be

written

in

infix

notation

In

the

following

the

first

two

columns

contain

examples

of

type

declaration

and

the

last

column

contains

subtype

specifications

leroy

student

john

faculty

student

person

jennifer

student

jeffrey

faculty

faculty

person

frank

student

frank

instructor

instructor

faculty

Suppose

that

we

have

the

following

query

p

-LRB-

X

-RRB-

q

-LRB-

X

-RRB-

-LRB-

-RRB-

where

p

is

applicable

to

only

students

and

q

is

applicable

to

only

instructors

To

verify

that

-LRB-

-RRB-

is

well-typed

one

may

try

to

find

a

suitable

type

for

the

variable

X.

Traditional

type

systems

either

assume

a

set

of

basic

types

that

are

disjoint

with

each

other

and

build

union

types

out

of

the

basic

types

or

assume

a

semi-lattice

structure

over

types

such

that

any

non-empty

set

of

basic

types

has

a

unique

greatest

lower

bound

We

take

a

slightly

more

general

approach

and

introduce

an

intensional

parameter

to

serve

as

a

constructor

for

intersection

types

-LRB-

defined

later

-RRB-

Then

in

the

above

we

could

assign

the

intersection

type

student

instructor

-LRB-

written

in

infix

notation

-RRB-

to

X

so

that

type

constraints

of

both

p

and

q

in

-LRB-

-RRB-

will

be

satisfied

On

the

other

hand

if

in

-LRB-

-RRB-

p

is

applicable

to

only

integers

and

q

is

applicable

to

only

strings

we

would

want

to

claim

that

the

query

is

ill-typed

on

the

grounds

that

int

string

being

a

uniformly

empty

type

can

not

be

meaningfully

assigned

to

a

variable

In

the

semi-lattice

approach

there

is

usually

a

bottom

element

which

indicates

a

type

error

and

is

usually

assigned

the

empty

domain

All

other

types

must

have

a

non-empty

domain

We

may

follow

the

same

approach

and

require

that

all

types

assigned

to

variables

must

have

nonempty

domains

Unfortunately

this

has

undesirable

effect

on

the

notion

of

well-typing

making

it

dependent

on

the

current

state

of

type

extensions

-LRB-

i.e.

on

which

terms

belong

to

which

type

in

the

current

state

of

the

database

-RRB-

For

instance

suppose

that

frank

graduates

from

the

university

and

resigns

from

his

instructor

's

job

Then

if

frank

was

the

last

student-instructor

in

the

database

the

query

-LRB-

-RRB-

will

suddenly

become

ill-typed

for

the

type

student

instructor

will

now

have

an

empty

domain

To

eliminate

this

undesirable

dependence

on

accidental

aspects

of

type

extensions

we

postulate

that

only

eligible

types

can

be

used

to

type

logical

variables

Normally

a

type

would

be

deemed

eligible

if

its

domain

is

not

uniformly

empty

-LRB-

i.e.

it

is

non-empty

for

at

least

some

valid

database

states

-RRB-

However

in

this

paper

we

shall

sidestep

the

problem

of

uniform

emptiness

-LRB-

which

is

known

to

be

decidable

for

Horn

predicate

logic

-RRB-

and

instead

will

adopt

a

more

general

view

of

eligibility

Namely

we

add

one

additional

intensional

parameter

eligible

whose

semantics

can

be

given

via

axioms

such

as

those

in

Section

Eligibility

can

then

be

relegated

to

the

sphere

of

user

declarations

so

that

a

type

o

will

be

considered

eligible

if

and

only

if

the

predicate

eligible

-LRB-

o

-RRB-

is

a

logical

consequence

of

the

program

-LRB-

and

axioms

-RRB-

If

o

is

an

eligible

type

it

can

then

be

used

in

a

type

assignment

for

an

object

variable

regardless

of

whether

the

database

currently

knows

of

an

object

o

such

that

o

o

holds

-LCB-

the

only

consideration

here

is

that

o

must

be

declared

as

an

eligible

type

that

int

and

string

have

their

intended

meanings

of

course

The

parameters

and

provide

adequate

typing

for

the

intensional

parameters

in

S.

However

typing

of

predicates

and

functions

requires

more

work

First

we

introduce

a

special

type

bool

to

represent

terms

that

evaluate

to

boolean

values

in

a

type-correct

way

Predicate

types

then

become

special

cases

of

functional

types

with

bool

as

the

range

type

We

use

another

special

intensional

parameter

-RRB-

for

constructing

functional

types

For

example

-RRB-

-LRB-

int

int

int

-RRB-

is

a

type

of

a

binary

function

over

objects

of

type

int

Following

the

standard

convention

we

will

use

infix

notation

here

and

write

int

int

-RRB-

int

instead

of

-RRB-

-LRB-

int

int

int

-RRB-

It

is

also

convenient

to

have

another

special

type

all

to

represent

the

supertype

of

all

types

Note

that

bool

is

just

a

type-name

which

by

convention

stands

for

the

type

of

all

well-typed

atomic

formulas

it

has

no

other

inherent

connection

with

the

Boolean

values

true

and

false

or

with

the

HiLog

subdomain

Utrue

For

most

purposes

we

could

use

all

in

lieu

of

bool

just

as

well

However

we

shall

see

that

bool

allows

more

precise

typing

As

discussed

in

Section

when

parameterized

types

interact

with

type

hierarchies

it

is

not

enough

to

specify

just

the

argument-types

and

the

range-type

of

a

function

Consider

a

type

specification

for

a

version

of

the

familiar

cons-operator

h-cons

that

is

used

to

build

homogeneous

lists

h-cons

list

-LRB-

-RRB-

-RRB-

list

-LRB-

-RRB-

-LRB-

-RRB-

A

homogeneous

list

is

a

list

of

elements

whose

members

all

belong

to

exactly

the

same

set

of

types

For

instance

consider

the

following

hierarchy

typically

supported

in

Prolog

systems

integer

number

float

number

number

atomic

atom

atomic

Here

a

list

of

integers

and

a

list

of

atoms

would

be

homogeneous

However

a

mixed

list

of

integers

and

atoms

would

be

not

More

interestingly

a

list

of

numbers

some

of

which

are

integers

while

others

are

floats

is

not

homogeneous

even

though

every

integer

or

float

is

also

a

number

This

is

because

not

all

numbers

have

exactly

the

same

set

of

types

As

explained

in

the

introduction

the

quantification

of

in

-LRB-

-RRB-

should

be

viewed

as

universal

However

this

is

not

enough

to

ensure

that

terms

that

are

constructed

out

of

h-cons

and

conform

to

-LRB-

-RRB-

represent

homogeneous

lists

only

Indeed

a

non-homogeneous

list

such

as

h-cons

-LRB-

h-cons

-LRB-

-RRB-

-RRB-

conforms

to

-LRB-

-RRB-

since

whenever

for

some

the

arguments

of

h-cons

belong

to

the

types

and

list

-LRB-

-RRB-

respectively

the

resulting

list

belongs

to

list

-LRB-

-RRB-

as

well

-LRB-

in

this

case

the

only

's

that

cover

the

arguments

of

this

term

are

number

atomic

and

all

-RRB-

One

proposal

for

remedying

this

problem

due

to

Reddy

-LSB-

-RSB-

involves

so

called

implication

types

Another

approach

due

to

Kifer

and

Wu

-LSB-

-RSB-

uses

type

dependencies

-LRB-

abbr

TD

-RRB-

The

two

approaches

are

related

but

both

unfortunately

blend

two

separate

issues

-LCB-

argument

constraints

and

functional

types

-LCB-

into

one

notion

Our

approach

builds

on

-LSB-

-RSB-

but

we

distinguish

between

argument

constraints

and

functional

types

which

leads

to

a

simpler

and

cleaner

formalism

In

addition

argument

constraints

apply

to

all

functional

types

while

in

-LSB-

-RSB-

only

predicates

can

be

typed

and

so

type

dependencies

have

no

effect

on

function

symbols

Finally

and

most

importantly

unlike

-LSB-

-RSB-

our

new

framework

is

syntactically

sound

in

the

sense

of

Section

Type

dependencies

are

designed

to

capture

the

inter-dependency

among

the

types

of

arguments

in

a

function

For

the

parameter

h-cons

in

-LRB-

-RRB-

the

appropriate

type

dependencies

would

be

and

The

first

TD

says

that

for

each

if

the

first

argument

is

of

type

the

second

must

be

of

type

list

-LRB-

-RRB-

Similarly

for

the

second

TD

It

is

thus

clear

that

two

distinct

concepts

are

at

work

here

the

functional

type

specification

-LRB-

-RRB-

and

a

pair

of

constraints

on

the

arguments

to

h-cons

It

is

easy

to

see

that

for

instance

the

aforesaid

non-homogeneous

list

h-cons

-LRB-

h-cons

-LRB-

-LSB-

-RSB-

-RRB-

-RRB-

fails

the

second

TD

since

the

second

argument

of

the

first-level

h-cons

h-cons

-LRB-

-LSB-

-RSB-

-RRB-

-RRB-

is

a

list

of

integers

but

the

first

argument

is

not

Formally

an

n-ary

TD

is

a

statement

of

the

form

lhs

rhs

where

lhs

rhs

ng

In

formal

treatment

below

it

will

be

convenient

to

encode

n-ary

TDs

as

binary

strings

of

the

form

ln

rn

where

each

li

and

ri

is

either

or

The

TD

lhs

rhs

corresponding

to

such

a

string

is

determined

as

follows

lhs

fi

j

li

and

rhs

fi

j

ri

For

instance

for

h-cons

is

encoded

as

An

n-ary

argument

constraint

over

an

intensional

parameter

f

S

can

now

be

represented

as

an

atomic

formula

f

-LRB-

on

ln

rn

-RRB-

where

the

oi

's

are

types

of

the

arguments

of

f

and

each

lj

rk

is

either

or

The

rightmost

arguments

encode

the

TD

lhs

rhs

above

Coming

back

to

h-cons

its

argument-constraints

can

be

represented

as

follows

-LRB-

-RRB-

h-cons

-LRB-

ff

h-list

-LRB-

-RRB-

-RRB-

-LRB-

-RRB-

h-cons

-LRB-

ff

h-list

-LRB-

-RRB-

-RRB-

Since

the

above

encoding

is

hard

to

read

we

shall

use

the

following

more

readable

notation

-LRB-

-RRB-

h-cons

-LRB-

ff

h-list

-LRB-

-RRB-

-RRB-

-LRB-

-RRB-

h-cons

-LRB-

ff

h-list

-LRB-

-RRB-

-RRB-

Furthermore

we

will

often

collect

all

TDs

in

one

place

and

write

-LRB-

-RRB-

h-cons

-LRB-

ff

h-list

-LRB-

-RRB-

-RRB-

-LRB-

-RRB-

with

the

understanding

that

-LRB-

-RRB-

is

actually

a

conjunction

of

formulas

Finally

it

often

happens

that

the

types

used

in

an

argument

constraint

and

those

used

on

the

left-hand

side

of

a

functional

type

are

the

same

For

instance

for

h-cons

we

could

write

-LRB-

-RRB-

-LRB-

h-cons

h-list

-LRB-

-RRB-

-RRB-

h-list

-LRB-

-RRB-

-RRB-

-LRB-

-RRB-

to

replace

both

-LRB-

-RRB-

and

-LRB-

-RRB-

It

should

be

mentioned

that

with

the

additional

type

dependencies

h-cons

-LRB-

-LSB-

-RSB-

-RRB-

is

not

well-typed

as

one

would

expect

assuming

the

standard

specification

of

-LSB-

-RSB-

list

-LRB-

-RRB-

The

reason

is

that

-LSB-

-RSB-

can

be

of

type

list

-LRB-

integer

-RRB-

but

is

not

of

type

integer

violating

the

type

dependency

of

h-cons

One

simple

solution

is

to

use

a

function

-LRB-

-RRB-

list

-LRB-

-RRB-

Then

h-cons

-LRB-

-LRB-

float

-RRB-

-RRB-

would

be

a

well-typed

homogeneous

list

This

seems

to

be

a

small

price

to

pay

to

support

both

parametric

and

inclusion

polymorphism

in

a

largely

untyped

language

like

HiLog

A

more

systematic

solution

is

to

use

an

explicitly

typed

framework

as

in

-LSB-

-RSB-

where

each

-LRB-

untyped

-RRB-

term

is

annotated

with

a

type

The

semantics

of

type

dependencies

can

then

be

defined

in

terms

of

arguments

type

annotations

instead

of

the

set

of

all

types

determined

by

the

value

of

each

argument

However

we

will

not

go

into

further

details

of

such

an

approach

in

this

paper

Axioms

for

the

Special

Intensional

Parameters

The

special

intensional

parameters

of

the

previous

subsection

were

introduced

with

certain

intended

meaning

in

mind

For

instance

must

be

transitive

and

should

be

commutative

This

special

meaning

can

either

be

built

into

the

semantics

of

HiLog

as

we

did

for

or

it

can

be

represented

via

logical

axioms

We

chose

the

latter

approach

and

the

axioms

of

HiLog

are

listed

below

Greek

letters

are

used

for

type

variables

and

Latin

capital

letters

for

object

variables

All

free

variables

are

assumed

to

be

universally

quantified

ffl

Subtypes

and

equality

-LRB-

reflexivity

-RRB-

X

-LRB-

X

-RRB-

-LRB-

type

membership

-RRB-

-LRB-

-RRB-

-LRB-

transitivity

of

-RRB-

-LRB-

-RRB-

-LRB-

acyclicity

-RRB-

ffl

Intersection

types

and

all

X

all

all

-LRB-

all

is

a

type

of

everything

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

properties

of

X

-LRB-

-RRB-

-LRB-

X

X

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

associativity

-RRB-

-LRB-

commutativity

-RRB-

-LRB-

idempotency

-RRB-

ffl

Eligible

types

eligible

-LRB-

-RRB-

X

-LRB-

non-empty

types

-RRB-

eligible

-LRB-

-RRB-

-LRB-

eligible

-LRB-

-RRB-

-RRB-

-LRB-

propagation

to

supertypes

-RRB-

ffl

Typing

for

and

special

parameters

-RRB-

bool

eligible

all

-RRB-

bool

all

all

-RRB-

bool

all

all

-RRB-

bool

These

axioms

are

self-explanatory

and

do

not

need

further

comments

However

it

is

worth

pointing

out

the

following

interesting

consequence

of

the

typing

axiom

for

Indeed

this

axiom

says

that

we

do

not

automatically

grant

that

X

Y

is

a

boolean

term

because

application

of

to

terms

of

different

types

is

bound

to

fail

To

be

considered

a

legal

bool-ean

term

both

arguments

of

must

be

instances

of

exactly

the

same

set

of

types

The

axioms

for

argument

constraints

are

more

involved

and

need

some

preparation

It

was

observed

in

-LSB-

-RSB-

that

type

dependencies

are

reminiscent

of

functional

dependencies

-LSB-

-RSB-

in

that

they

are

axiomatizable

by

the

well-known

Armstrong

's

axioms

We

remind

these

axioms

here

using

X

Y

and

Z

to

denote

subsets

of

ng

list

only

axioms

that

are

not

already

built

into

the

semantics

of

HiLog

In

particular

most

of

the

axioms

for

are

not

listed

explicitly

as

the

special

meaning

of

follows

from

the

definitions

in

Section

Reflexivity

If

Y

X

then

X

Y

Augmentation

If

X

Y

then

X

-LSB-

Z

Y

-LSB-

Z.

Transitivity

If

X

Y

and

Y

Z

then

X

Z

If

a

TD

td

follows

from

another

set

of

TDs

tdn

by

Armstrong

's

axioms

we

specify

this

fact

as

tdn

TD

td

A

linear

algorithm

for

testing

TD

appears

in

-LSB-

-RSB-

Let

c

be

an

argument

constraint

f

-LRB-

on

lhs

rhs

-RRB-

M

hU

I

F

Utruei

be

a

semantic

structure

of

HiLog

and

let

be

a

variable

assignment

for

M

The

denotation

of

c

denoted

-LSB-

c

-RSB-

M

is

the

set

of

all

tuples

dni

Un

that

satisfy

at

least

one

of

the

following

ffl

for

some

i

lhs

-LRB-

I

-LRB-

:-RRB-

-RRB-

-LRB-

-RRB-

F

-LRB-

di

-LRB-

oi

-RRB-

-RRB-

Utrue

ffl

for

every

j

rhs

-LRB-

I

-LRB-

:-RRB-

-RRB-

-LRB-

-RRB-

F

-LRB-

dj

-LRB-

oj

-RRB-

-RRB-

Utrue

Recall

that

-LRB-

I

-LRB-

:-RRB-

-RRB-

-LRB-

-RRB-

F

in

the

above

is

the

interpretation

of

as

a

binary

function

In

other

words

dni

-LSB-

c

-RSB-

M

if

and

only

if

whenever

di

is

in

type

oi

for

every

i

lhs

then

dj

is

also

in

type

oj

for

every

j

rhs

Note

that

the

denotation

of

c

does

not

depend

on

f

in

TDs

names

of

the

intensional

parameters

play

the

role

of

tags

needed

to

identify

constraints

that

apply

to

the

same

symbol

-LRB-

for

the

purpose

of

TD-inference

-RRB-

This

is

analogous

to

functional

dependencies

which

must

be

tagged

with

relation

names

in

order

to

make

proper

inferences

Let

C

be

a

set

of

n-ary

argument

constraints

on

a

symbol

f

and

let

c

be

another

such

constraint

of

f

We

say

that

C

entails

c

denoted

C

j

c

if

and

only

if

for

every

semantic

structure

M

that

satisfies

the

axioms

for

-LRB-

reflexivity

acyclicity

and

transitivity

-RRB-

and

every

variable

assignment

it

holds

that

-LSB-

c

-RSB-

M

-LSB-

c

-RSB-

M

This

condition

says

that

every

tuple

that

satisfies

all

constraints

in

C

also

satisfies

c.

Proposition

below

shows

that

the

notion

of

entailment

for

argument

constraints

satisfies

the

first

axiom

for

argument

constraints

ffl

Axioms

for

argument

constraints

F

-LRB-

n

td

-RRB-

F

-LRB-

n

tdk

-RRB-

if

tdn

TD

td

F

-LRB-

n

lhs

rhs

-RRB-

F

-LRB-

n

lhs

rhs

-RRB-

-LRB-

i

i

-RRB-

-LRB-

i

i

-RRB-

The

first

axiom

here

clarifies

the

role

of

TDs

in

argument

constraints

The

second

axiom

is

nothing

but

the

usual

property

of

functional

types

of

the

form

lhs

-RRB-

rhs

It

thus

states

that

argument

constraints

behave

similarly

to

functional

types

of

certain

kind

Proposition

A

set

C

of

n-ary

argument

constraints

for

some

parameter

f

entails

another

n-ary

constraint

c

for

the

same

parameter

f

if

and

only

if

C

-LSB-

fAxioms

for

argument

constraintsg

j

c

The

axiomatization

for

functional

types

is

standard

this

algorithm

was

developed

for

functional

dependencies

in

relational

databases

it

applies

to

TD

's

because

of

their

Armstrong

's

axiomatization

ffl

Functional

types

X

-LRB-

n

-RRB-

-RRB-

X

-LRB-

n

-RRB-

-RRB-

-LRB-

-RRB-

-LRB-

n

n

-RRB-

-LRB-

-RRB-

The

conventional

wisdom

says

that

given

types

for

the

intensional

parameters

and

variables

the

type

of

any

complex

term

t

-LRB-

tn

-RRB-

can

also

be

determined

provided

that

t

has

an

appropriate

functional

type

o

However

as

demonstrated

earlier

in

polymorphic

systems

with

subtypes

it

is

not

enough

to

require

the

types

of

tn

to

match

the

argument-types

of

o

As

we

have

shown

argument

constraints

must

also

be

taken

into

account

To

this

end

we

change

the

usual

axiom

for

function

application

as

follows

ffl

Function

application

F

-LRB-

Xn

-RRB-

F

n

-RRB-

-LRB-

Xn

n

-RRB-

n

i

j

-LRB-

-LSB-

F

-LRB-

n

i

j

-RRB-

-LRB-

Xi

i

-RRB-

-RSB-

oe

Xj

j

-RRB-

where

Vi

j

is

a

conjunction

over

all

TDs

such

that

i

j

ng

The

last

antecedent

in

the

application

axiom

states

that

arguments

to

F

must

satisfy

all

argument

constraints

associated

with

F

The

reader

can

verify

that

with

the

type

declaration

-LRB-

-RRB-

the

term

h-cons

-LRB-

h-cons

-LRB-

-LRB-

integer

-RRB-

-RRB-

-RRB-

is

non-typable

i.e.

it

is

not

assigned

any

type

by

the

above

axioms

thereby

providing

grounds

for

dismissing

it

as

an

illegal

construct

Finally

we

note

that

robustness

with

respect

to

subtyping

one

of

the

properties

on

the

list

of

desiderata

in

Section

comes

about

precisely

due

to

the

last

axiom

above

the

axiom

of

function

application

Type

Correctness

The

following

is

a

full-fledged

program

for

h-append

a

predicate

for

appending

homogeneous

lists

It

contains

both

type

declarations

and

object-level

definitions

-LRB-

A

-RRB-

h-list

-LRB-

A

-RRB-

h-cons

A

h-list

-LRB-

A

-RRB-

-RRB-

h-list

-LRB-

A

-RRB-

h-append

h-list

-LRB-

A

-RRB-

h-list

-LRB-

A

-RRB-

h-list

-LRB-

A

-RRB-

-RRB-

bool

eligible

-LRB-

h-list

-LRB-

A

-RRB-

-RRB-

eligible

-LRB-

A

-RRB-

h-append

-LRB-

-LRB-

A

-RRB-

L

L

-RRB-

L

h-list

-LRB-

A

-RRB-

h-append

-LRB-

h-cons

-LRB-

X

-RRB-

h-cons

-LRB-

X

-RRB-

-RRB-

h-append

-LRB-

-RRB-

X

A

h-list

-LRB-

A

-RRB-

We

also

assume

that

there

are

some

eligible

types

such

as

integer

float

etc.

Intuitively

the

above

program

is

well-typed

because

every

clause

complies

with

all

type

declarations

This

concept

is

formalized

for

Horn

programs

in

Section

Then

in

Section

it

is

extended

to

cover

clauses

with

negation

Horn

Clause

Programs

Let

P

be

a

program

and

let

A

denote

the

set

of

all

axioms

in

Section

A

type

assignment

T

is

a

finite

set

of

atomic

formulas

of

the

form

X

o

where

X

is

a

variable

o

is

a

ground

term

and

A

-LSB-

P

j

eligible

-LRB-

o

-RRB-

for

each

such

o

T

Consider

a

Horn

clause

L

Ln

-LRB-

-RRB-

It

is

well-typed

if

each

of

the

following

holds

ffl

for

every

type

assignment

T

A

-LSB-

P

j

-LRB-

-RRB-

-LRB-

T

bool

Ln

bool

oe

L

bool

-RRB-

-LRB-

-RRB-

ffl

there

exists

a

type

assignment

T

such

that

A

-LSB-

P

j

-LRB-

-RRB-

-LRB-

T

oe

-LRB-

bool

Ln

bool

-RRB-

-RRB-

where

-LRB-

-RRB-

denotes

universal

closure

of

a

formula

With

n

the

above

conditions

determine

when

positive

unit-clauses

are

well-typed

this

happens

precisely

when

A

-LSB-

P

j

-LRB-

-RRB-

-LRB-

T

oe

L

bool

-RRB-

for

all

T

When

T

is

fixed

and

A

-LSB-

P

j

-LRB-

T

oe

L

bool

-RRB-

we

can

say

that

L

is

well-typed

relatively

to

T

Also

it

can

be

easily

verified

that

condition

-LRB-

-RRB-

above

is

equivalent

to

A

-LSB-

P

j

-LRB-

-RRB-

-LRB-

-LRB-

T

oe

bool

-RRB-

-LRB-

T

oe

Ln

bool

-RRB-

oe

-LRB-

T

oe

L

bool

-RRB-

-RRB-

This

leads

to

the

following

interpretation

of

our

notion

of

well-typing

A

clause

is

well-typed

if

and

only

if

-LRB-

i

-RRB-

every

type

assignment

that

well-types

each

body-atom

also

well-types

the

head

and

-LRB-

ii

-RRB-

there

is

a

type

assignment

that

well-types

every

atom

in

the

body

Note

that

conditions

-LRB-

i

-RRB-

and

-LRB-

ii

-RRB-

here

guarantee

syntactic

adequacy

of

our

notion

of

typecorrectness

Indeed

they

ensure

that

there

is

at

least

one

type

assignment

that

well-types

each

atom

in

each

rule

of

the

logic

program

This

requirement

holds

even

for

rules

that

may

never

fire

because

their

premises

are

not

satisfied

in

the

current

database

-LRB-

or

never

-RRB-

This

behavior

should

be

contrasted

with

the

type

systems

in

-LSB-

-RSB-

which

are

not

sound

syntactically

-LRB-

although

they

are

semantically

sound

-RRB-

As

mentioned

previously

pure

clauses

in

our

program

for

h-append

are

well-typed

However

if

we

replace

the

last

pair

of

clauses

there

with

h-append

-LRB-

-LRB-

A

-RRB-

L

L

-RRB-

h-append

-LRB-

h-cons

-LRB-

X

-RRB-

h-cons

-LRB-

X

-RRB-

-RRB-

h-append

-LRB-

-RRB-

then

the

result

is

no

longer

well-typed

The

first

clause

is

ill-typed

since

the

type

assignment

T

fL

integerg

ill-types

the

head

of

this

clause

while

at

the

same

time

it

trivially

well-types

the

empty

body

of

that

clause

In

the

second

clause

the

reason

for

ill-typing

is

more

subtle

since

X

does

not

occur

in

the

body

there

is

no

way

to

relate

the

type

of

X

with

the

type

of

This

leads

to

the

possibility

of

deriving

atoms

of

the

form

h-append

-LRB-

-RRB-

that

use

or

define

lists

that

are

not

homogeneous

For

another

example

consider

number

p

-LRB-

X

-RRB-

q

-LRB-

X

-RRB-

integer

number

q

-LRB-

-RRB-

p

integer

-RRB-

bool

q

number

-RRB-

bool

The

clause

for

p

is

ill-typed

there

is

a

type

assignment

T

that

ill-types

the

clause

p

-LRB-

X

-RRB-

q

-LRB-

X

-RRB-

namely

T

fX

numberg

The

next

example

illustrates

the

use

of

intersection

types

p

tutor

-RRB-

bool

stud

emp

tutor

r

stud

-RRB-

bool

eligible

-LRB-

stud

emp

-RRB-

q

emp

-RRB-

bool

p

-LRB-

X

-RRB-

r

-LRB-

X

-RRB-

q

-LRB-

X

-RRB-

This

is

a

well-typed

program

There

is

only

one

type

assignment

that

makes

the

body

well-typed

T

fX

stud

empg

Clearly

T

also

well-types

the

head

Compared

to

other

proposals

such

as

-LSB-

-RSB-

we

do

not

require

that

there

will

be

an

object

that

belongs

to

both

stud

and

emp

All

we

need

is

that

in

principle

stud

and

empl

will

be

intersectable

i.e.

that

eligible

-LRB-

stud

emp

-RRB-

will

be

inferable

Note

that

without

the

notion

of

intersection

types

the

above

program

would

have

been

well-typed

only

if

stud

and

emp

had

a

common

subtype

say

tutor

Theorem

Let

P

be

a

well-typed

program

Then

every

atom

that

is

true

in

the

least

Herbrand

model

of

P

is

well-typed

This

theorem

ensures

that

type-less

computation

with

well-typed

programs

can

not

produce

illtyped

answers

which

is

the

semantic

soundness

property

discussed

in

Section

A

brief

look

at

the

definition

of

well-typing

should

convince

that

the

use

of

bool

is

not

essential

there

We

could

do

almost

as

well

by

replacing

bool

with

all

However

the

use

of

the

finer

type

bool

instead

of

a

rather

crude

type

all

increases

the

precision

with

which

illtyped

constructs

can

be

detected

For

instance

we

could

define

Prolog

's

meta-predicate

call

as

follows

call

-LRB-

X

-RRB-

X

call

bool

-RRB-

bool

This

typing

is

more

precise

than

call

all

-RRB-

all

for

it

would

reject

the

atom

call

-LRB-

h-cons

-LRB-

-LRB-

integer

-RRB-

-RRB-

-RRB-

while

accepting

call

-LRB-

h-append

-LRB-

-LRB-

integer

-RRB-

h-cons

-LRB-

-LRB-

integer

-RRB-

-RRB-

-RRB-

-RRB-

a

distinction

that

the

type

declaration

call

all

-RRB-

all

is

unable

to

make

Before

leaving

this

subsection

we

give

a

few

examples

of

type

reflexivity

of

our

system

i.e.

the

ability

to

query

the

very

type

structure

of

a

program

This

feature

is

a

direct

consequence

of

the

fact

that

types

are

represented

intensionally

via

regular

first-order

terms

and

of

the

fact

that

argument

constraints

are

atomic

formulas

in

HiLog

For

instance

h-list

-LRB-

integer

-RRB-

X

h-cons

X

Y

-RRB-

h-list

-LRB-

number

-RRB-

employee

T

are

queries

that

return

all

supertypes

of

the

type

h-list

-LRB-

integer

-RRB-

the

argument

types

of

h-cons

and

the

type

of

employee

respectively

If

employee

is

a

relation

in

a

database

the

last

query

will

return

its

schema

The

querying

and

integration

of

database

schema

is

required

in

heterogeneous

database

systems

More

complex

examples

of

this

kind

can

be

found

in

-LSB-

-RSB-

Clauses

with

Negation

We

conclude

the

discussion

of

the

notion

of

well-typedness

by

showing

how

it

can

be

extended

to

clauses

with

negation

As

in

predicate

calculus

the

declarative

semantics

of

a

program

is

now

given

via

canonical

models

such

as

the

well

founded

partial

model

-LSB-

-RSB-

In

our

case

all

axioms

of

Section

have

to

be

included

-LRB-

as

before

the

set

of

these

axioms

is

denoted

by

A

-RRB-

These

axioms

except

for

the

axiom

of

function

application

are

already

in

clausal

forms

The

function

application

axiom

can

be

converted

into

clausal

forms

in

the

standard

manner

Let

M

-LRB-

P

-LSB-

A

-RRB-

denote

the

canonic

model

of

P

augmented

with

the

axioms

of

Section

The

first

difference

with

the

Horn

case

is

that

now

we

can

no

longer

use

the

logical

entailment

relation

j

to

determine

what

is

implied

by

P

So

the

definition

of

type-correctness

needs

adjustment

by

replacing

A

-LSB-

P

with

M

-LRB-

P

-LSB-

A

-RRB-

The

next

question

is

what

to

do

with

negative

literals

One

approach

is

to

treat

negative

literals

the

same

way

as

positive

ones

-LRB-

for

the

purpose

of

typing

of

course

-RRB-

However

this

would

violate

the

principle

of

semantic

adequacy

introduced

in

Section

That

is

some

true

atoms

may

no

longer

conform

to

the

declared

typing

Consider

the

following

program

p

integer

-RRB-

bool

p

-LRB-

X

-RRB-

r

-LRB-

X

-RRB-

q

-LRB-

X

-RRB-

q

integer

-RRB-

bool

r

-LRB-

-RRB-

r

number

-RRB-

bool

integer

number

-LRB-

-RRB-

If

we

treat

q

-LRB-

X

-RRB-

the

same

way

as

q

-LRB-

X

-RRB-

the

clause

for

p

would

be

well-typed

since

there

is

exactly

one

type

assignment

for

X

namely

integer

that

makes

the

body

well-typed

This

assignment

well-types

the

head

as

well

and

so

the

program

would

have

to

be

considered

well-typed

Now

the

atom

p

-LRB-

-RRB-

violates

the

typing

for

p

and

yet

is

true

in

M

-LRB-

P

-RRB-

which

points

to

a

hole

in

the

type

system

To

correct

the

problem

and

restore

the

semantic

adequacy

we

could

resort

to

a

stronger

notion

of

type-correctness

by

ignoring

negative

literals

in

clause

bodies

i.e.

by

considering

them

well-typed

no

matter

what

This

however

would

make

the

rules

such

as

:p

-LRB-

h-cons

-LRB-

-RRB-

-RRB-

type

correct

which

considerably

weakens

the

ability

of

the

type

system

to

detect

programming

mistakes

A

solution

that

we

adopt

here

is

based

on

type-checking

the

arguments

of

the

negative

literals

before

discarding

these

literals

In

other

words

suppose

that

the

clause

-LRB-

-RRB-

may

also

contain

negative

literals

in

its

body

We

shall

say

that

a

clause

-LRB-

-RRB-

is

well-typed

if

and

only

if

ffl

For

every

type

assignment

T

M

-LRB-

P

-RRB-

j

-LRB-

-RRB-

-LRB-

T

Ln

oe

L

-RRB-

-LRB-

-RRB-

ffl

There

exists

a

type

assignment

T

such

that

M

-LRB-

P

-RRB-

j

-LRB-

-RRB-

-LRB-

T

oe

-LRB-

Ln

-RRB-

-RRB-

-LRB-

-RRB-

Here

L

is

defined

as

follows

ffl

If

L

is

a

positive

literal

then

L

is

L

bool

ffl

If

L

is

a

negative

literal

of

the

form

A

-LRB-

Tk

-RRB-

then

L

is

all

Tk

all

We

can

now

see

why

-LRB-

-RRB-

is

ill-typed

the

assignment

T

fX

numberg

makes

the

body

welltyped

but

the

head

remains

ill-typed

under

this

assignment

The

result

of

Theorem

now

extends

like

this

Theorem

If

P

is

well-typed

and

M

-LRB-

P

-LSB-

A

-RRB-

is

a

canonic

model

of

A

and

P

-LRB-

say

the

perfect

or

the

well-founded

model

-RRB-

then

all

true

atoms

in

M

-LRB-

P

-LSB-

A

-RRB-

are

well-typed

Conclusion

We

have

analyzed

the

very

notion

of

type

correctness

and

drafted

a

list

of

adequacy

requirements

for

a

type

system

in

logic

programming

A

powerful

framework

has

been

developed

for

specifying

polymorphic

type

systems

for

a

higher-order

logic

language

HiLog

which

meets

all

of

the

requirements

Our

framework

generalizes

and

integrates

the

syntactic

and

model-theoretic

approaches

to

types

in

logic

programming

The

type

of

each

non-logical

parameter

and

variable

fits

all

syntactic

contexts

in

which

the

parameter

or

variable

occurs

Semantically

all

ground

atoms

that

are

true

in

a

canonical

model

semantics

of

a

well-typed

program

are

also

well-typed

This

applies

to

arbitrary

logic

programs

with

negation

including

definite

programs

as

a

special

case

The

standard

treatment

of

parametric

polymorphism

collapses

when

inclusion

polymorphism

is

present

In

particular

when

there

is

a

type

all

that

is

a

supertype

of

all

other

types

the

co-reference

constraints

by

type

variables

in

polymorphic

types

become

vacuous

We

extended

the

concept

of

type

dependencies

in

-LSB-

-RSB-

to

enforce

dependencies

among

argument

types

of

predicates

as

well

as

those

of

functions

thereby

retaining

the

benefits

of

both

parametric

and

inclusion

polymorphism

Types

in

HiLog

are

dynamic

they

are

specified

by

the

user

via

facts

and

rules

in

the

same

way

as

predicates

are

defined

in

logic

programs

An

implication

is

that

type

specifications

can

be

queried

and

evaluated

in

the

same

manner

This

property

has

interesting

applications

to

database

schema

manipulation

and

heterogeneous

databases

Although

compile

time

type

checking

remains

an

important

technique

in

logic

programming

run

time

type

checking

is

required

in

general

when

inclusion

polymorphism

is

present

In

systems

such

as

Prolog

-LSB-

-RSB-

types

determine

the

basic

operation

of

unification

The

dynamic

treatment

of

types

in

HiLog

attempts

to

support

run

time

type

checking

in

a

general

setting

Limitation

of

space

does

not

permit

us

to

expand

on

type

checking

In

general

type

correctness

is

undecidable

However

this

does

not

foreclose

the

study

of

various

subsystems

for

which

well-typing

may

be

decidable

or

where

sufficiently

general

type

checking

is

possible

One

such

system

is

a

derivative

of

-LSB-

-RSB-

However

unlike

in

-LSB-

-RSB-

in

our

framework

parametric

polymorphism

no

longer

collapses

in

the

presence

of

subtyping

Another

advantage

is

that

the

type

structure

in

our

case

can

itself

be

queried

The

notion

of

type

inference

and

type

checking

under

partial

type

inference

can

be

defined

as

in

-LSB-

-RSB-

However

the

actual

algorithms

for

type

inference

need

further

study

For

certain

relatively

simple

type

systems

e.g.

-LSB-

-RSB-

the

existing

algorithms

can

be

converted

to

work

in

our

framework

References

-LSB-

-RSB-

H.

Azzoune

Type

inference

in

Prolog

In

Proceedings

of

International

Conference

on

Automated

Deduction

pages

-LCB-

-LSB-

-RSB-

C.

Beeri

and

P.A.

Bernstein

Computational

problems

related

to

the

design

of

normal

form

relational

schemes

ACM

Transactions

on

Database

Systems

-LRB-

-RRB-

-LCB-

March

-LSB-

-RSB-

M.

Bruynooghe

Adding

redundancy

to

obtain

more

reliable

and

more

readable

Prolog

programs

In

Proceedings

of

the

First

International

Logic

Programming

Conference

pages

-LCB-

Marseille

France

-LSB-

-RSB-

W.

Chen

M.

Kifer

and

D.S.

Warren

HiLog

A

first-order

semantics

for

higher-order

logic

programming

constructs

In

North

American

Conference

on

Logic

Programming

-LRB-

NACLP

-RRB-

October

-LSB-

-RSB-

W.

Chen

M.

Kifer

and

D.S.

Warren

HiLog

A

foundation

for

higher-order

logic

programming

Journal

of

Logic

Programming

-LRB-

-RRB-

-LCB-

February

-LSB-

-RSB-

A.G.

Cohn

A

more

expressive

formulation

of

many

sorted

logic

Journal

of

Automated

Reasoning

-LCB-

-LSB-

-RSB-

R.

Dietrich

and

F.

Hagl

A

polymorphic

type

system

with

subtypes

for

Prolog

In

Proceedings

of

the

European

Symp

on

Programming

Lecture

Notes

in

Computer

Science

pages

-LCB-

Springer

Verlag

-LSB-

-RSB-

H.B.

Enderton

A

Mathematical

Introduction

to

Logic

Academic

Press

-LSB-

-RSB-

T.

Fruehwirth

Type

inference

by

program

transformation

and

partial

evaluation

In

IEEE

Intl.

Conf

on

Computer

Languages

pages

-LCB-

Miami

Beach

FL

-LSB-

-RSB-

T.

Fruehwirth

Polymorphic

type

checking

for

Prolog

in

HiLog

In

Israel

Conference

on

Artificial

Intelligence

and

Computer

Vision

Tel

Aviv

Israel

-LSB-

-RSB-

T.

Fruewirth

E.

Shapiro

M.Y.

Vardi

and

E.

Yardeni

Logic

programs

as

types

for

logic

programs

In

Intl.

Symposium

on

Logic

in

Computer

Science

-LRB-

LICS

-RRB-

pages

-LCB-

Amsterdam

The

Netherlands

July

-LSB-

-RSB-

M.

Hanus

Polymorphic

higher-order

programming

in

prolog

In

Intl.

Conference

on

Logic

Programming

-LRB-

ICLP

-RRB-

pages

-LCB-

Lisboa

Portugal

MIT

Press

-LSB-

-RSB-

M.

Hanus

Parametric

order-sorted

types

in

logic

programming

Technical

Report

Universitaet

Dortmund

Fachbereich

Informatik

Dortmund

FRG

January

-LSB-

-RSB-

M.

Hanus

Logic

programming

with

type

specifications

In

F.

Pfenning

editor

Types

in

Logic

Programming

pages

-LCB-

The

MIT

Press

-LSB-

-RSB-

N.

Heintze

and

J.

Jaffar

A

finite

presentation

theorem

for

approximating

logic

programs

In

ACM

Symposium

on

Principles

of

Programming

Languages

-LRB-

POPL

-RRB-

pages

-LCB-

-LSB-

-RSB-

P.

Hill

and

R.

Topor

A

semantics

for

typed

logic

programs

In

F.

Pfenning

editor

Types

in

Logic

Programming

pages

-LCB-

The

MIT

Press

-LSB-

-RSB-

D.

Jacobs

Type

declarations

as

subtype

constraints

in

logic

programming

In

Proceedings

of

the

ACM

Conference

on

Programming

Language

Design

and

Implementation

pages

-LCB-

June

-LSB-

-RSB-

T.

Kanamori

and

K.

Horiuchi

Type

inference

in

Prolog

and

its

application

In

Intl.

Joint

Conference

on

Artificial

Intelligence

-LRB-

IJCAI

-RRB-

pages

-LCB-

-LSB-

-RSB-

M.

Kifer

G.

Lausen

and

J.

Wu

Logical

foundations

of

object-oriented

and

frame-based

languages

Technical

Report

-LRB-

a

revision

of

-RRB-

Department

of

Computer

Science

SUNY

at

Stony

Brook

April

To

appear

in

Journal

of

ACM

Available

in

Z

by

anonymous

ftp

to

cs.sunysb.edu

-LSB-

-RSB-

M.

Kifer

and

J.

Wu

A

first-order

theory

of

types

and

polymorphism

in

logic

programming

In

Intl.

Symposium

on

Logic

in

Computer

Science

-LRB-

LICS

-RRB-

pages

-LCB-

Amsterdam

The

Netherlands

July

Expanded

version

TR

under

the

same

title

Department

of

Computer

Science

University

at

Stony

Brook

July

-LSB-

-RSB-

P.

Mishra

Towards

a

theory

of

types

in

Prolog

In

IEEE

Symposium

on

Logic

Programming

-LRB-

SLP

-RRB-

pages

-LCB-

-LSB-

-RSB-

P.

Mishra

and

U.S.

Reddy

Declaration-free

type

checking

In

ACM

Symposium

on

Principles

of

Programming

Languages

-LRB-

POPL

-RRB-

pages

-LCB-

-LSB-

-RSB-

A.

Mycroft

and

R.A.

O'Keefe

A

polymorphic

type

system

for

Prolog

Artificial

Intelligence

-LCB-

-LSB-

-RSB-

G.

Nadathur

and

F.

Pfenning

Types

in

higher-order

logic

programming

In

F.

Pfenning

editor

Types

in

Logic

Programming

pages

-LCB-

The

MIT

Press

-LSB-

-RSB-

G.

Phipps

M.A.

Derr

and

K.A.

Ross

Glue-Nail

A

deductive

database

system

In

ACM

SIGMOD

Conference

on

Management

of

Data

pages

-LCB-

-LSB-

-RSB-

C.

Pyo

and

U.S.

Reddy

Inference

of

polymorphic

types

for

logic

programs

In

North

American

Conference

on

Logic

Programming

-LRB-

NACLP

-RRB-

pages

-LCB-

-LSB-

-RSB-

U.

Reddy

A

perspective

on

types

for

logic

programs

unpublished

notes

-LSB-

-RSB-

U.S.

Reddy

Notions

of

polymorphism

for

predicate

logic

programs

In

Joint

Intl.

Conference

and

Symposium

on

Logic

Programming

-LRB-

JICSLP

-RRB-

MIT

Press

August

Paper

presented

at

the

conference

and

distributed

as

an

addendum

to

the

proceedings

-LSB-

-RSB-

K.A.

Ross

On

negation

in

HiLog

In

ACM

SIGACT-SIGMOD-SIGART

Symposium

on

Principles

of

Database

Systems

-LRB-

PODS

-RRB-

pages

-LCB-

May

-LSB-

-RSB-

K.A.

Ross

Relations

with

relation

names

as

arguments

Algebra

and

calculus

In

ACM

SIGACT-SIGMOD-SIGART

Symposium

on

Principles

of

Database

Systems

-LRB-

PODS

-RRB-

May

-LSB-

-RSB-

G.

Smolka

Logic

programming

with

polymorphically

order-sorted

types

In

J.

Grabowski

P.

Lescanne

and

W.

Wechler

editors

Algebraic

and

Logic

Programming

volume

of

Lecture

Notes

in

Computer

Science

pages

-LCB-

Springer-Verlag

-LSB-

-RSB-

B.

Stroustrup

The

C++

Programming

Language

Addison-Wesley

Reading

MA

-LSB-

-RSB-

J.F.

Ullman

Principles

of

Database

and

Knowledge-Base

Systems

Volume

Computer

Science

Press

-LSB-

-RSB-

A.

Van

Gelder

K.A.

Ross

and

J.S.

Schlipf

The

well-founded

semantics

for

general

logic

programs

In

ACM

SIGACT-SIGMOD-SIGART

Symposium

on

Principles

of

Database

Systems

-LRB-

PODS

-RRB-

pages

-LCB-

-LSB-

-RSB-

J.

Wu

A

Theory

of

Types

and

Polymorphism

in

Logic

Programming

PhD

thesis

SUNY

at

Stony

Brook

-LSB-

-RSB-

J.

Xu

and

D.S.

Warren

A

type

inference

system

for

Prolog

In

Joint

Intl.

Conference

and

Symposium

on

Logic

Programming

-LRB-

JICSLP

-RRB-

pages

-LCB-

-LSB-

-RSB-

J.

Xu

and

D.S.

Warren

Semantics

of

types

in

logic

programming

Manuscript

-LSB-

-RSB-

E.

Yardeni

T.

Fruehwirth

and

E.

Shapiro

Polymorphically

typed

logic

programs

In

Intl.

Conference

on

Logic

Programming

-LRB-

ICLP

-RRB-

Paris

France

June

-LSB-

-RSB-

J.

Zobel

Derivation

of

polymorphic

types

for

Prolog

programs

In

Proceedings

of

the

Fourth

International

Logic

Programming

Conference

pages

-LCB-

Melbourne

Australia

MIT

Press

argument constraint
reflexive type system
type dependency
types

semantic and syntactic adequacy of type system