Issue CONS-TYPE-SPECIFIER Writeup

Issue:        CONS-TYPE-SPECIFIER

Forum:	      EDITORIAL

References:   Issue PRETTY-PRINT-INTERFACE,

	      Issue ATOMIC-TYPE-SPECIFIER-LIST,

	      Issue RECURSIVE-DEFTYPE

Category:     ADDITION

Edit history: 05-Feb-91, Version 1 by Pitman

	      15-Mar-91, Version 2 by Pitman

	      08-Apr-91, Version 3 by Pitman 

	        (integrate amendment to option ADD from Mar-91 meeting)

Status:	      X3J13 passed option ADD on a vote of 12-1, March 1991.


Problem Description:


  The description of the pretty printer dispatching mechanism is complicated

  by the fact that dispatch cannot be described in terms of `type specifiers'.

  In fact, the pretty printer dispatches on either a type specifier -or- a

  list whose car is CONS.


Proposal (CONS-TYPE-SPECIFIER:ADD):


  Permit the CONS type specifier to be a type specifier that specializes,

  with the syntax:


    (CONS [type-specifier-1 [type-specifier-2]])


  Either type specifier may be *, which means the same as T.

  Either the second type specifier or both type specifiers may be omitted.

  Omitted type specifiers default to T.


  Extend the CONS pretty printer dispatcher to treat (CONS) the same as CONS.


Test Case:


  (TYPEP '(A B C) 'CONS)   => T			; Already true

  (TYPEP '(A B C) '(CONS T)) => T		; New with this proposal

  (TYPEP '(A B C) '(CONS SYMBOL)) => T		; New with this proposal

  (TYPEP '(A B C) '(CONS INTEGER)) => NIL	; New with this proposal

  (TYPEP '(A B C) '(CONS T T)) => T		; New with this proposal

  (TYPEP '(A B C) '(CONS SYMBOL SYMBOL)) => NIL	; New with this proposal

  (TYPEP '(A B C) '(CONS SYMBOL (CONS SYMBOL (CONS SYMBOL))))

   => T						; New with this proposal

  (TYPEP '(A B C) '(CONS SYMBOL (CONS SYMBOL (CONS SYMBOL NIL))))

   => NIL					; New with this proposal

  (TYPEP '(A B C) '(CONS SYMBOL (CONS SYMBOL (CONS SYMBOL NULL))))

   => T						; New with this proposal


Rationale:


  This will make the description of the pretty printer simpler with no 

  substantial overhead for other parts of the system.


  This same approach was taken for EQL type specifiers in CLOS, so that

  all method specializers could have corresponding type specifiers.


Current Practice:


  Probably no one implements this.


Cost to Implementors:


  Very small.


Cost to Users:


  None.


Cost of Non-Adoption:


  Extra conceptual overhead in the specification.  A new term will have to be

  devised for pprint `type specifiers' in order to avoid telling lies all over

  the place about some things being type specifiers that really aren't (or to 

  avoid being overly verbose all over the place if we decide to tell the full

  truth every time the issue comes up.)


Benefits:


  This new type specifier might be turn out to be useful in its own right in

  some applications.


Aesthetics:


  I think this improves the aesthetics.


Discussion:


  This was discussed previously and discarded.  But having looked at the 

  complexity it introduces in to the specification, I think it needs to be

  reopened.


  The question of what (TYPEP '(A B C) '(CONS)) returns was spun off as

  a separate issue named ATOMIC-TYPE-SPECIFIER-LIST.


  Barmar got briefly excited about the idea of 

   (deftype proper-list (&optional (element-type t))

     `(or null (cons ,element-type proper-list)))

  but others didn't like it.  A separate issue RECURSIVE-DEFTYPE addresses

  this.


  Allan Wechsler (Symbolics) notes that 

    (deftype list-of-length (length)

      (if (= 0 length)

	  'null

	  `(cons t (list-of-length ,(- length 1)))))

  would in principle be reasonable under this proposal.