References: Issue PRETTY-PRINT-INTERFACE,
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.
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.
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.
(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
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.
Probably no one implements this.
Cost to Implementors:
Cost to Users:
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.)
This new type specifier might be turn out to be useful in its own right in
I think this improves the aesthetics.
This was discussed previously and discarded. But having looked at the
complexity it introduces in to the specification, I think it needs to be
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
Allan Wechsler (Symbolics) notes that
(deftype list-of-length (length)
(if (= 0 length)
`(cons t (list-of-length ,(- length 1)))))
would in principle be reasonable under this proposal.