Xiaochu Qi Department of Computer Science and Engineering University of Minnesota

Download Presentation

Xiaochu Qi Department of Computer Science and Engineering University of Minnesota

Loading in 2 Seconds...

- 57 Views
- Uploaded on
- Presentation posted in: General

Xiaochu Qi Department of Computer Science and Engineering University of Minnesota

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Treatment of Types in an Implementation of λProlog Organized around Higher-Order Pattern Unification

Xiaochu Qi

Department of Computer Science and Engineering

University of Minnesota

- descriptive notion:
- typed Prolog
- parametric polymorphism
type nil (list A).

type :: A -> (list A) -> (list A).

type append (list A) -> (list A) -> (list A) -> o.

- prescriptive notion:
- λProlog
- mixed usage of parametric and ad hoc polymorphism
type print_int int -> o.

type print_str string -> o.

type print A -> o.

print X :- print_int X.

print X :- print_str X.

print X.

- a polymorphic version of the simply typed λ-calculus
- atomic types: including type variables
- the intuitive meaning of a term t :σ
{t :σ’|σ’ is a closed instance of σ }

- a strongly typed language
- type declarations for constants
- inferring types for all subterms

- prevent run-time failures
- well-typedness: compile time type-checking

- participate in unification

universal variable

existential variable

constant

?- (F)(append (c::nil) nil (F c)).

∀c ∀:: ∀nil ∀append F

?- (F)∀c(append (c::nil) nil (F c)).

∀:: ∀nil ∀append F ∀c

- The occurrences of a constant can have different types.
- The occurrences of a universal or existential variable must always have identical types.

type nil (list A).

type :: A -> (list A) -> (list A).

(1 :: nil)

(“a” :: nil)

(1:int :::int->(list int)->(list int) nil:(list int))

(“a”:string :::string->(list string)->(list string) nil:(list string))

- determine the identity of constants
- decide the structures of unifiers
- Types are associated with every variable and constant.

- determine the identity of constants
- a universal or existential variable:
- always has identical types in different occurrences
- can have a polymorphic type, which could be specialized during unification

- processing terms in a top-down manner
- iterative usage of:
- term simplification phase:
- simply non-existential variable head applications

- binding phase
- decide the structure of bindings for existential variables

- term simplification phase:

- iterative usage of:
- invariant:
Terms to be unified always have identical types.

- term simplification phase:
- constant heads: examine (specialize) the types of these
constants

- others: already have identical types

- constant heads: examine (specialize) the types of these
- binding phase:
- identical types of the entire terms
- identical types of relevant variables
- no comparison on constants
- No need for type examination

∀g F ∀c X ∀a

type g A -> B.

τ(c)= A->B τ(a)= C

τ(X)= C->A τ(F)= (A->B)->int

<(g (c (X a))) , (g (F c))>

<(g:B->D (c:A->B (X:C->A a:C)),

(g:int->D (F:(A->B)->int c:A->B))>

(r-r): {<B, int>}

<c:A->int (X:C->A a:C), F:(A->int)->int c:A->int>

(r-f): {<F, λc(c (H c))>}

∀g HF ∀c X ∀a

<X:C->A a:C, H:(A->int)->A c:A->int>

(f-f): {<X, λc(H’ a)>, <F, λc(c (H’ c))>}

∀1 ∀”a” ∀f X Y ∀c

type f A -> B -> C.

τ(c)= A->B

τ(X)= A τ(Y)= B

<(f X “a” (c X)) , (f 1 Y (c Y))>

<f:A->string->B->C X:A “a”:string (c:A->B X:A),

f:int->A->B->C 1:int Y:A (c:A->B Y:A)>

- only associating types with constants

Exp1: ∀g F ∀c X ∀a

<(g:B->D (c:A->B (X:C->A a:C)),

(g:int->D (F:(A->B)->int c:A->B))>

<(g:B->D (c (Xa)), (g:int->D (F c))>

Exp2: ∀1 ∀”a” ∀f X Y

<f:A->string->B->C X:A “a”:string (c:A->B X:A),

f:int->A->B->C 1:int Y:A (c:A->B Y:A)>

<f:A->string->B->C X “a” (c X),

f:int->A->B->C1 Y (c Y)>

Exp1: <(g:B->D (c (Xa)), (g:int->D (F c))>

<(g:[B,D] (c (Xa)), (g:[int,D] (F c))>

- well-typedness with respect to type declarations
- compile time type-checking

- instances of type variables
- run time type-checking

(:: (:: X nil) nil)

(:::(list A)->(list (list A))->(list (list A))

(:::A->(list A)->(list A)Xnil:(list A))

nil:(list (list A)))

(:::[list A] (:::[A] X nil:[A]) nil:[list A])

- Type variables occurring in target types have been checked at a upper level.
- Constant function symbols:
- type variables not occurring in target types

- Non-function constants: no need to maintain types

type :: A -> (list A) -> (list A).

type nil (list A).

(:::[list A](:::[A] X nil:[A]) nil:[list A])

(::(:: X nil) nil)

type g (A -> B) -> A.

type a int -> B.

(:::[int] (g:[int,B] a:[int,B]) nil:[int])

(:: (g [B] a) nil)

type id (list A) -> (list A) -> o.

id nil nil.

id (X::L) (X::K) :- id L K.

Teyjus:

id A (:: A X L) (:: A X K) :- id A L K.

Our scheme:

id A (:: X L) (:: X K) :- id A L K.

?- id (1::nil) T.

Teyjus:

?- id int (:: int 1 nil) T.

Our scheme:

?-id int (:: 1 nil) T.

<(:: A X L), (:: int 1 nil)>

(read mode)

<(:: A X K), T>

(write mode)

<A, int>

bind (A, int);

<(:: X L), (:: 1 nil)>

bind (X, 1);

bind (L, nil);

bind (T, (:: A S2 K));

bind (A, int);

bind (S2, X);

<(:: X K), T>

bind (T, (:: S2 K));

- Typed Prolog :
type p σ1 -> … -> σn -> o.

p t1 … tn :- b1, …, bm.

- τ(t1)= σ1, …, τ(tn)= σn
- Every sub-term of tiis type preserving.

- Only type general and preserving programs are well-typed.

- mixed usage of parametric and ad hoc polymorphism

type print A -> o.

type print_int int -> o.

type print_str string -> o.

print X :- print_int X.

print X :- print_string X.

print X.

- type generality and preservation property should hold on every clause head defining a predicate.

type foo A -> o.

foo X :- print X.

- type variables of the clause head should not be used in body goals.

- Type examination is necessary in higher-order pattern unification.
- Reduce type association and run-time type examination
- constant function symbols
- separate static and dynamic information
- take advantage of the type preservation property

- prove the correctness of the typed higher-order pattern unification scheme
- taking advantage of the type generality property
- making usage in implementations