From tfm%computer-lab.cambridge.ac.uk@NSFnet-Relay.AC.UK  Tue Aug 22 17:44:30 1989
Received: by iris (5.57/3.14)
        id AA20587; Tue, 22 Aug 89 16:54:05 PDT
Received: from ucdavis.ucdavis.edu by clover.ucdavis.edu (5.59/UCD.EECS.1.11)
        id AA03097; Tue, 22 Aug 89 16:33:23 PDT
Received: by ucdavis.ucdavis.edu (5.51/UCD1.41)
        id AA00123; Tue, 22 Aug 89 16:23:03 PDT
Received: from computer-lab.cambridge.ac.uk by NSFnet-Relay.AC.UK
           via Janet with NIFTP  id aa07782; 22 Aug 89 22:14 BST
Received: from steve.cl.cam.ac.uk by scaup.Cl.Cam.AC.UK id aa15335;
          22 Aug 89 22:11 BST
Date: Tue, 22 Aug 89 22:05:31 BST
From: Tom Melham <tfm%computer-lab.cambridge.ac.uk@NSFnet-Relay.AC.UK>
To: info-hol%clover.ucdavis.edu@NSFnet-Relay.AC.UK
Subject: non-compatible changes proposed for type defn package.
Message-Id:  <8908222211.aa15335@scaup.Cl.Cam.AC.UK>

---------------------------------------------------------------------
CHANGES associated with the NEW TYPE DEFINITION PACKAGE for HOL
---------------------------------------------------------------------

This note is intended to give users of the HOL88 type definition package (and
HOL users in general) advance notice of some changes that I hope to make in
connection with some extensions to the HOL88 type definition package.

I would appreciate any feedback from users (positive or negative) on the
following proposed changes.  If no-one objects strongly, I will probably make
all these changes (except, maybe, number 5) when implementing the extended
type definition package. (The first release of the package should be ready in
the near future).

1) A number of users have been inconvenienced by the built-in constants
   o, S, K, and I (all combinators, with the usual definitions).  If there
   is strong enough support for this proposal, I'll re-do all the built-in
   proofs that rely on these constants and then remove them. (So that
   the symbols o, S, K and I can be variables).  Users will then have to
   define their own combinators, or I could but the current combinator theory
   in the library.

2) Currently, the type definition package will prime the names of
   constructors that happen to be constants already.  E.g:

        #let thm = define_type `one` `ty = NIL`;;
        thm = |- !e. ?! fn. fn NIL' = e

   Note that NIL gets primed, since it's already a constant.  The proposal
   is to change this, so that define_type will fail with an appropriate
   error message in situations like this.

3) I intend to re-write the parser for type definitions (the code that
   parses the second argument to define_type) in order to fix bugs like:

        #let thm = define_type `type` `type = C (num # num)`;;
        evaluation failed     hd

        #let thm = define_type `type` `type = C (num#num)`;;
        thm = |- !f. ?! fn. !p. fn(C p) = f p

   There's no real problem with the first call to define_type; the current
   (prototype) parser just can't handle the spaces that surround the "#"
   symbol.  The new parser will fix this.

4) The built-in type (*)TREE will be changed to (*)ltree to avoid problems
   with case-insensitive implementations of HOL.

5) I'm not too sure about this one, so any opinions would be appreciated.
   Currently, the user has no choice about the ordering of the parameters
   to defined type operators.  E.g:

        #let thm = define_type `op` `op = REC * **`;;
        thm = |- !f. ?! fn:(*,**)op-> ***. !x0 x1. fn(REC x0 x1) = f x0 x1

   Note that the type operator comes out to be (*,**)op, rather than (**,*)op.
   The user in fact has no choice --- define_type just parameterizes in the
   order in which type variables occur on the rhs of the definition.

   The question is: is it worth changing the syntax for defining type
   operators so that the user has to explicitly parameterize the operator
   being defined?  E.g., for the above type the new syntax would be:

       #let thm = define_type `op` `(*,**)op = REC * **`;;

   Or, alternatively:

       #let thm = define_type `op` `(**,*)op = REC * **`;;

   Note: there IS a difference between these two.

   For a recursive type operator, the new syntax would (for example) be:

       #let thm = define_type `op` `(*,**)op = C ** * | REC (*,**)op`;;

   But the following would fail:

       #let thm = define_type `op` `(*,**)op = C ** * | REC (**,*)op`;;

   This would give the user control over the order in which type variables
   appear in the aguments to the defined type operator.  (There are cases
   in which it may make a difference...).  On the other hand, it makes the
   syntax of define_type more complex.  There seem to be three options:


        a) leave it as it is (no explicit parameters)

        b) force the user to always write explicitly
           parameterized type operators (as in the
           examples shown above).

        c) somehow support both (a) and (b).

   Any comments? (Option (a) would obviously be the easiest option for me.)

I may not be able to reply for a couple of weeks, but if you have comments on
the above points, please send them to me by e-mail.

Tom

