Issue: LIST-TYPE-SPECIFIER (Version 1)

[masinter.pa@Xerox.COM]

Michael J. Beckerle:

Please reply if you get this... If you want to pursue this, can you produce
a new draft of the proposal quickly? Please let us know what your schedule
is.

The summary so far is that there are possibly two kinds of type specifier
syntax:

(<list-consisting-of-all> NUMBER)
	for example, (1 2 12323)
(<list-with-explicit-elements> NUMBER SYMBOL)
	for example, (1 A)

For the second type of description, there are some design choices about
whether "extra" arguments are legal, e.g., is

(typep '(1 A 3) '(<list-with-explicit-elements> NUMBER SYMBOL)) 

valid? There might be a possibility of using the function argument list
notation, e.g.,

(<list-with-explicit-elements> NUMBER SYMBOL &KEY (:FROB NUMBER)
&ALLOW-OTHER-KEYS)

which would lead to the recursive ambiguity of 
(<list-with-explicit-elements> &REST (<list-with-explicit-elements>
NUMBER))

(:->)

- - - - - - - -
For whatever additional type descriptors one might add, the question could
be whether an implementation which had a new kind of LIST which was not
read-only and not completely writable, but for which it would be an error
to modify the structure of the list so that it no longer conformed to a
predefined type specification.

This proposal would interact with TYPE-OF-UNDERSPECIFIED (would (TYPE-OF
'(1 2)) be allowed to return (<list-with-explicit-elements> (MEMBER 1)
(MEMBER 2))?)

Given the desired semantics, there is then some debate about what the
*name* of the type specifiers might be; the proposed names LIST and LIST-OF
could arguably be applied to either kind of specifier.

I not personally  inclined to pursue this issue. The fact that there is a
feature that several people want is not one of the more serious ones.