Issue METACLASS-OF-SYSTEM-CLASS Writeup

Issue:        METACLASS-OF-SYSTEM-CLASS

Reference:    X3J13/92-102, dpANS 12.24

                Section 4.3.7, "Integrating Types and Classes", p.4-16..418

              X3J13/92-3105, Kim Barrett comment #5

Category:     CHANGE

Edit History: Version 1, 1/6/93, Kim Barrett

Status:       Proposal UNSPECIFIED accepted, March 1993


Problem Description:


 The fifth and seventh paragraphs on p.4-17 say


  Each \term{class} that corresponds to a predefined \term{type specifier}

  can be implemented in one of three ways, at the discretion of each

  implementation.  It can be a \term{standard class}, a

  \term{structure class}, or a \term{built-in class}.


  It is possible to determine whether a \term{class} is a

  \term{built-in class} by checking the \term{metaclass}.  A

  \term{standard class}  is an \term{instance} of \theclass{standard-class},

  a \term{built-in class}  is an \term{instance} of

  \theclass{built-in-class}, and a \term{structure class} is an

  \term{instance} of \theclass{structure-class}.


 This prohibits implementations from using implementation-specific metaclasses

 which are not subclasses of one of the three defined metaclasses

 (STANDARD-CLASS, STRUCTURE-CLASS, and BUILT-IN-CLASS).  This prohibition

 gratuitously limits implemention freedom, since it serves no useful purpose

 for users.


 Depending on how the uses of the term \term{instance} are disambiguated in

 the second paragraph, it may actually be making the stronger requirement that

 \term{direct instances} of these metaclasses be used.


Proposal (METACLASS-OF-SYSTEM-CLASS:UNSPECIFIED):


 Change the fifth paragraph on p.4-17 by replacing the occurance of the term

 \term{built-in class} with the term \term{system class}, so that it says


  Each \term{class} that corresponds to a predefined \term{type specifier}

  can be implemented in one of three ways, at the discretion of each

  implementation.  It can be a \term{standard class}, a

  \term{structure class}, or a \term{system class}.


Editorial Impact:


 One tiny edit.


Rationale:


 Allows system classes to be implemented using implementation specific

 metaclasses that are not themselves subclasses of any of the standardized

 metaclasses, and therefore can be implemented in whatever manner is

 deemed appropriate by the implementor without the need to override possibly

 undesirable features of the inherited standardized metaclass.


Examples:


 (typep (find-class 'stream)

        '(or standard-class structure-class built-in-class))

 \EV \term{implementation-dependent}


Current Practice:


 Of the half dozen implementations I checked, none obeyed even the

 weaker of requirements mentioned in the problem description.


Cost to Implementors:


 None.  This does not require any implementation to change.


Cost to Users:


 Small.  Any program that was specializing some generic function on

 standard-class, structure-class, and built-in-class (with the idea that this

 covered all the possibilities) would have to change.  Such a program is

 already non-portable.  The obvious change is to instead specialize on class.


Performance Impact:


 None.


Discussion:


 This issue was discussed extensively in private mail during February 1992,

 under the Subject line "implementation of a system class".