From tfm%computer-lab.cambridge.ac.uk@NSFnet-Relay.AC.UK  Wed Nov 29 02:38:43 1989
Received: by iris (5.57/3.14)
        id AA07115; Wed, 29 Nov 89 02:38:43 PST
Received: from ucdavis.ucdavis.edu by clover.ucdavis.edu (5.59/UCD.EECS.1.11)
        id AA10842; Wed, 29 Nov 89 02:42:09 PST
Received: by ucdavis.ucdavis.edu (5.51/UCD1.41)
        id AA14860; Wed, 29 Nov 89 02:35:30 PST
Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK
           via Janet with NIFTP  id aa03084; 29 Nov 89 10:24 GMT
Received: from steve.cl.cam.ac.uk by scaup.Cl.Cam.AC.UK id aa05576;
          29 Nov 89 10:18 GMT
Date: Wed, 29 Nov 89 10:13:43 GMT
From: Tom Melham <tfm%computer-lab.cambridge.ac.uk@NSFnet-Relay.AC.UK>
To: info-hol%clover.ucdavis.edu@NSFnet-Relay.AC.UK
Subject: new_recursive_definition
Message-Id:  <8911291018.aa05576@scaup.Cl.Cam.AC.UK>

FUNCTION DEFINITIONS made using new_recursive_definition
--------------------------------------------------------


In Phil's recent message about implementing assocation lists in HOL, he
noted that he:

+---------------------------------------------------------------------
|... couldn't get the type package to accept it in the form I wanted, so here
| is a theorem that IS in the coorect form (Tom, am I doing something wrong
| or does the type package not like pairs as variables?):
+---------------------------------------------------------------------

Phil is not doing anything wrong. The current implementation of
recursive function definitions just does not allow definitions
with pairs in place of variables on the left hand sides of equations
(except, of course, when ty1#ty2 is the concrete type on which the
function is being defined).

I hope to eliminate this restriction in the near future. But, for now,
here is an outline of what the package allows at present.

Suppose ty is defined by

let ty_Axiom = define_type `ty` `ty = ... | C ty1 ty2 ... tyn | ...`;;

Then a typical (recursive) function definition on ty would have the
form:

let FN = new_recursive_definition false ty_Axiom `FN`
         "... /\
          FN x1 ... xi  (C t1 ... tn) y1 ... yj = <rhs> /\
          ...";;

Where x1,...,xi,t1,...,tn,y1...,yj are VARIABLES only.

As I mentioned above, I hope to extend the package to allow other
things instead of variables in definitions of this form.  There are
many possible extensions, but the maximal prectical extension seems to
be to allow:

  1) the positions occupied by the variables x1,...,xn,y1,...,yn
     in the above definition to consist of any terms (of the
     appropriate types) constructed from the constructors of
     the built-in concrete types:

         bool, one, * # **, * + **, * list.

     I.e. each x1,...,xn,y1,...,yn could be a term tm with the syntax:

         tm ::= var | T | F | one | (tm,tm) |
                Inl tm | Inr tm | Nil | (Cons tm tm)

     subject, of course, to the obvious typing restrictions. And,

  2) such terms could also occur in the positions occupied by any
     of the variables t1,...,tn in the above definition which are
     are NOT of type ty. (This handles Phil's example.)

Note that the syntax of terms tm given above could, in principle, be
extended to include terms built up from the constructors of any concrete
recursive type currently defined in the HOL session in which the user
is working.  I'd hate to implement this, however. (It seems a bit ugly,
but I'm willing to change my mind.  Any comments?).

Does the above proposed extension (i.e. the simple one, which I'll
mention anyway at the HOL user's group meeting) look useful enough
to give implementing it priority?

Tom

(PS: oh yes, whatever is done... we ought to make new_definition
     consistent with new_recursive_definition, with regard to
     varstructs).




