TYPECASEQ and the Type Hierarchy

[GLS at SU-AI (Guy Steele)]

I recommend the introduction of a TYPECASEQ (CASET? but that parses
also as C-ASET or CA-SET) construction.  The advantage of it
over simply (CASEQ (TYPEP ...) ...) is that it can permit the
use of names for sets of types, the precise components of which
the user is not concerned with (and indeed may not want to
be concerned with for reasons of transportability).

It is interesting to consider the hierarchy of data types in NIL;
here is a picture (somewhat incomplete, and the names may not
be the preferred ones):
				OBJECT
				/    \
			       /       \
			   ATOM       LIST
			  /    \     /    \
			 /      \   /      \
    -------------------------  SELFLIST    PAIR (or CONS)
    |     |     |     |     |	    | \
   ARRAY  |  SYMBOL   | CHARACTER   () others
	  |           |
	VECTOR     NUMBER
	/ | \      /  |  \
  STRING  | etc  FIX  |  COMPLEX
        BIT     / | FLOAT   |   \
	    INUM  |  | \   PLAIN BIG
	     BIGNUM  |  \
		  FLONUM BIGFLOAT

There are many other interesting relationships not shown here;
one might divide the types into INOB and STOB; also there ought
to be a word for a non-selflist atom.  Anyway, the point is that
it is not a tree, but a partial order.

Using these names, one might write:
	(TYPECASEQ FOO
		   ((NUMBER) <do arithmetic>)
		   ((SYMBOL CHARACTER) <be symbolic>)
		   ((LIST SEXPVEC) <be recursive>)
		   (T <be obnoxious>))
Now it might be convenient to permit the categories named not to be
mutually exclusive, but to permit some overlap.  This would make it
easy to specify exceptions; e.g. for FIX numbers to go one way,
and all other numbers, whatever they may be, another way.  I suggest
the discipline that overlap be allowed between two categories only
if one is a strict superset of the other, and then it is the branch
for the latter that is chosen.  (This prevents confusion in the
case of, e.g., (TYPECASEQ '() ((ATOM) ...) ((LIST) ...)).)

As for implementation, this can be made a macro provided that
the macro is aware of all the types and categories and their
relationships, and expands the clauses into a CASEQ on TYPEP
(or whatever).  The macro would check for the superset relationship
among categories, and then expand all categories into
their lowest-level constituents.  It is likely that
the types and categories distinguishable by TYPECASEQ would
extend below the level of the main type code, and so the
macro expansion may want to be trickier than what I have outlined.
The implementation, whether as macro or fexpr, is likely
to be machine-dependent because it may know about low-level types,
and so it is desirable to institutionalize it in the language.
Indeed, its expansion could involve a numeric CASEQ on the
primitive storage data type, lending it speed when compiled.

-------