Re: (SYMBOL? #t) ==> ?

[andy%hobbes@ads.com (Andy Cromarty)]

I am concerned that specifying type disjointedness gets us into the
very messy business of

(a) unintentionally and unnecessarily specifying implementation details and
(b) reinforcing the distinction between system-defined and user-defined types.

For example, it should be possible for an implementor to choose to implement
vectors as tagged lists, if lists happen to be unusually efficient in this
implementation (or vice-versa).   It appears to me that we do not (yet)
subscribe to the TYPEP model, in which an object "has a type," and that it
is good that we don't.  Instead, we treat types as attributes of an object
-- consider (INTEGER? 3) and (NUMBER? 3) -- allowing us to recognize more
cleanly in our code that (a) an object may have several attributes and 
(b) there may (or may not) be important relationships between those attributes.

This suggests that if v is a vector and p a pair, then (VECTOR? v) and
(PAIR? p) should be true, but (VECTOR? p) and (PAIR? v) should be
undefined in the Report (i.e. considered to be implementation-dependent).

If there are important counterexamples where it is necessary to know what
an object's type is, as distinct from knowing whether it satisfies the 
criteria of a given equivalence class, I suggest we bring out those examples 
directly for public scrutiny and discussion.  (They could lead to a more 
Common LISP-like type model.)  My intuition is that such a change is 
unnecessary and that Scheme's type model gives the software more latitude 
in defining the relationships between different types, given that 
[BEGIN OPINION]
the computer science community still seems to be mired in this abstract 
data practice of defining types in terms of other types 
[END OPINION],
and that instead we might wish to protect and capitalize on Scheme's
apparent underspecification of the types of objects and the relationships
that obtain between those type classes.

						asc

p.s. I suspect this represents an argument that (if '() #t #f)
     should be undefined in the Report (i.e. implementation-dependent).
     Of course, good programming practice would dictate the use of NULL?
     where the test-object is a (possibly-empty) list in either case.