Treatment of types in an implementation of prolog organized around higher order pattern unification
This presentation is the property of its rightful owner.
Sponsored Links
1 / 23

Xiaochu Qi Department of Computer Science and Engineering University of Minnesota PowerPoint PPT Presentation


  • 46 Views
  • Uploaded on
  • Presentation posted in: General

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. Types in Logic Programming Languages. descriptive notion: typed Prolog parametric polymorphism

Download Presentation

Xiaochu Qi Department of Computer Science and Engineering University of Minnesota

An Image/Link below is provided (as is) to download presentation

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

Presentation Transcript


Treatment of types in an implementation of prolog organized around higher order pattern unification

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


Types in logic programming languages

Types in Logic Programming Languages

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


Types in logic programming languages1

Types in Logic Programming Languages

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


The nature of polymorphism in prolog

The Nature of Polymorphism in λProlog

  • 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 σ }


The roles of types in prolog

The Roles of Types in λProlog

  • 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


A prefix of mixed quantifiers

universal variable

existential variable

constant

A Prefix of Mixed Quantifiers

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

∀c ∀:: ∀nil ∀append F

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

∀:: ∀nil ∀append F ∀c


Types of constants and variables

Types of Constants and Variables

  • 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))


Higher order unification

Higher-Order Unification

  • determine the identity of constants

  • decide the structures of unifiers

  • Types are associated with every variable and constant.


Higher order pattern unification

Higher-Order Pattern Unification

  • 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


Typed higher order pattern unification

Typed Higher-Order Pattern 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

  • invariant:

    Terms to be unified always have identical types.


Typed higher order pattern unification1

Typed Higher-Order Pattern Unification

  • term simplification phase:

    • constant heads: examine (specialize) the types of these

      constants

    • others: already have identical types

  • binding phase:

    • identical types of the entire terms

    • identical types of relevant variables

    • no comparison on constants

    • No need for type examination


Xiaochu qi department of computer science and engineering university of minnesota

∀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 HF ∀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))>}


Xiaochu qi department of computer science and engineering university of minnesota

∀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)>


Maintain types with constants

Maintain Types with Constants

  • 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)>


Maintain instances of type variables

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

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

Maintain instances of type variables

  • 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 preservation

Type Preservation

  • 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 processing effort in compiled unification

Type Processing Effort in Compiled Unification

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.


Type processing in compiled unification over id x l x k id 1 nil t

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

(read mode)

<(:: A X K), T>

(write mode)

Type Processing in Compiled Unification over<id (X::L) (X::K), id (1::nil) T>

<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));


Type generality

Type generality

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

  • λProlog :

    • mixed usage of parametric and ad hoc polymorphism


  • Type generality in prolog

    Type generality in λProlog

    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 generality in prolog1

    Type generality in λProlog

    type foo A -> o.

    foo X :- print X.

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


    Conclusion

    Conclusion

    • 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


    Future work

    Future work

    • prove the correctness of the typed higher-order pattern unification scheme

    • taking advantage of the type generality property

    • making usage in implementations


  • Login