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

[Pavel.pa@Xerox.COM]

Jon asks: ``Tell me how to write a symbolic differentiation program, or an
evaluator, that operates on the "obvious" s-expression inputs (e.g. the list (/
1 (sqrt (+ 1 x)))) in a world where the types number, pair, symbol are not
disjoint.''

Suppose that my only two disjoint types are characterized by the predicates
NULL? and PAIR?.  Then I can certainly define other types by making them lists
with various internal structures and unique, particular cons cells as ``tags''
in the car of the top-level cons-cell of the value.  Then my other predicates,
SYMBOL? and NUMBER?, simply check for PAIR? first and then test that the CAR is
the special cons cell for that type.  Thus, in such an implementation (please,
please keep in mind that I'm not necessarily in favor of the proposal and
certainly not in favor of this implementation; my reputation is at stake
here...) we would have the following implications:

	(number? x) => (pair? x)
	(symbol? x) => (pair? x)
	(number? x) => (not (symbol? x))
	(pair? x) => (not (null? x))

and no others not deducible from these.  I claim that in such a system I could
write the code you describe by simply checking number? and symbol? before
checking pair? at each point.

Note however, that while I've written (in the sense of a mathematician) the code
you requested, that code would not be portable to an implementation in which any
of the implications above were reversed.  In particular, if an implementation
represented symbols and pairs in terms of numbers (never mind about how they get
the right semantics for set-car!), my code would fail because I would be testing
for things in the wrong order.

Hmm.  This is a very persuasive argument against all kinds of things not being
disjoint.  I think I just firmly moved into the anti-proposal camp.  I think
that the issue is unrelated to questions of ``the type'' of an object and is
much more related to the question of which types I want to be able to
distinguish and treat differently.  In particular, Andy proposed that one
implementation might want to represent vectors by pairs and another might want
to do the reverse.  By the kind of portability argument I've just given, the
Scheme spec would have to specify that at least one of these was not legal, so
that I could figure out the proper portable order in which to test things.
However, I can see no reason to prefer one of these representation choices to
the other, so I would be forced to forbid both of them, since I certainly want
to be able to distinguish pairs and vectors.

Hmm.  I guess I'm really firmly in the disjointness camp.  I hope no one gets
whiplash reading this note...

	Pavel