Treatment of types in an implementation of prolog organized around higher order pattern unification
Download
1 / 23

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


  • 83 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Xiaochu Qi Department of Computer Science and Engineering University of Minnesota' - whitney


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