Re: which functions should be generic?

[Warren Harris <harris%hplwhh@hplabs.HP.COM>]

> It's difficult to implement COERCE's dispatch in terms of generic
> function dispatch since equivalence of type specifiers is not done
> in an object-oriented way. 

This could be handled in the same way as the PRINT-OBJECT generic function.
Implementations are required to call it from within their print system.
One could supply a COERCE-OBJECT generic function which the COERCE function
would ultimately call if the coercion argument named a class.  

I realize that one could probably find a large number of candidates in CLtL
to be made generic.  Ideally EQUAL should be generic too.  It already
depends on the type of objects you give it, looking inside of vectors, etc.
Why not allow it to look inside of objects in an object dependent way?

At some point the argument boils down to an efficiency consideration.  I
don't think anyone would be happy if EQ was required to be generic.  There
should be a strong rational for which functions are to be made generic and
which are not.  (For example:  how should the average user know when to use
ELT instead of SVREF?)  Perhaps a generic layer of CL is in order.  CL
already kind of does this with its sequence operations.  I can think of three
generic protocols off hand:

	- sequences which access subcomponents by position

	- objects and structures which access subcomponents by name

	- math functions which operate on generic "numbers"

It would be nice if CL had facilities for formally specifying the protocols
for abstract classes like NUMBER, SEQUENCE, or OBJECT (i.e. first class
protocol objects, or an abstract-class metaclass), and allow individual
classes to implement a protocol.  This way the user can write code that
meets a protocol without regard to the specifics of its implementation.