#

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

Copyright 1996-2001, Xanalys Inc. All rights reserved.