Loading in 5 sec....

Xiaochu Qi Department of Computer Science and Engineering University of MinnesotaPowerPoint Presentation

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...

- 71 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