Re: which functions should be generic?

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Fri, 24 Jun 88 16:37:03 PDT
    From: 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.  

But it's meaningful for COERCE's second argument to be a type specifier that
does not name a class.  CLtL gives as an example (vector (complex short-float)).
It would be inconsistent to do some coercions with classes and others through
some other mechanism.  I don't think your idea will work without a larger
recasting of Common Lisp in object-oriented terms.  While that's an interesting
project for investigation, I suspect it would quickly go way beyond the
proper charter of a standardization effort.

    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.

While I strongly agree with this, and have thought so for several years, again
I feel this is beyond the proper charter of a standardization effort.  There
does not appear to be any current practice at all, let alone a concensus from
which to build a standard.

Some of the directions in which I feel Lisp ought to evolve in the 1990s
include enormously better tools for modularity and program packaging,
like what such languages as Ada have but better conceived and (as always
in Lisp) more flexible (the "locales" found in some dialects in Scheme
might be a good place to start); formal notions of protocols and
machine-understandable interface specifications; complete integration of
database concepts into the language; and development tools that
"understand" both Lisp programming concepts and the dynamics of large
development teams.  None of this is X3J13's business, which is to
stabilize the Lisp of the 1980s so people can use it.