FLAVOR-CLASS, and Random metaclasses for CL types

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

    Date: Wed, 14 Jun 89 01:06:07 PDT
    From: Jon L White <jonl@lucid.com>

    I don't think we ever came to any resolution about your original
    query of Date: Wed, 10 May 89 13:31 EDT -- namely how to rewrite
    the paragraph on page 1-15 of 88-002R which spells out how the "holy"
    types can be implemented.

I'm not sure.  I have 20 messages saved on the topic and don't have time
to review them right now.

    But I see that several vendors are planning to offer a FLAVOR-CLASS
    as a tie-in with their native (or optional) flavors products (and Gregor
    mentioned he is working on a similar "hook" for PCL too).  That is, a 
    meta-class somewhat like STRUCTURE-CLASS that ensures that flavor types 
    (which are integrated with CL types in those products) also have 
    appropriately named CLOS classes behind them so that they can be 
    specialized upon.

    Why not mention this directly in the standard?  

I don't think it's at all appropriate to include the name FLAVOR-CLASS
in the standard.  What I do want to do to the standard is to make sure
that it doesn't accidentally contain language that would make it impossible
for an implementation to add FLAVOR-CLASS, OBJECT-LISP-CLASS, PCL-CLASS,
or any of several others.  I think this should be easy to do.