[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Indeed, one of us must be confused.
- To: Scott E. Fahlman <Fahlman at Cmu-20c>
- Subject: Indeed, one of us must be confused.
- From: DLW at MIT-MC
- Date: Tue, 28 Sep 1982 13:08:00 -0000
- Cc: Common-Lisp at SU-AI, Kent M. Pitman <KMP at MIT-MC>
- Sender: DLW at MIT-OZ
Well, I think the problem that is really at the heart of what
KMP is talking about is the same as something I brought up
at the meeting regarding TYPEP. KMP wants a function that
asks "can this very array support this optional feature",
whereas what he is given is a function that asks "might this
feature be supported by some implementation given something
of this 'type'?". He wants a way to ask whether a given
array object really cannot do certain operations. This is
a useful thing, but it is not provided mainly because C.L.
spends more time worrying about how to make the differences
invisible when they ought to be invisible, rather than how to
make them visible when they are visible. In the rubout-handler
example, VECTORP shouldn't be used; there should be a new function
or set of functions to test the array and report whether it can
or cannot handle the particular feature in question. VECTORP
is really wrong since, in the way KMP is trying to use it,
it tests the AND of several unrelated hairy array features;
using a specific feature tester predicate would be more powerful,
clear, and useful.