[Openmcl-devel] Building GSharp (Failure)

Gary Byers gb at clozure.com
Mon Oct 16 03:34:03 PDT 2006

On Mon, 16 Oct 2006, Nikodemus Siivola wrote:

> Gary Byers <gb at clozure.com> writes:
>> (deftype number () 'cl:number)
>> (setf (find-class 'number) (find-class 'cl-number))
>> The effect of the (SETF FIND-CLASS) is to make the class be the type
>> associated with the symbol GSHARP-NUMBERING:NUMBER, overriding the
>> (rather short-lived) DEFTYPE.  The idea behind the CERROR in this
>> situation is that - in general - changing a type definition in this
>> way is something that shouldn't be done casually.  (That might be a
>> little more convincing if there were references to the type - perhaps
>> TYPEP calls - between the DEFTYPE and the (SETF FIND-CLASS)).  In this
>> particular case, it barely matters (but so far I haven't seen a reason
>> for any GSharp package to have shadowed CL:NUMBER in the first place.)
> I cannot comment on the number/gsharp case, but as far as I can tell,
> 1. (SETF FIND-CLASS) should not make the class name into a type
>    specifier

The proper name of every class is a valid type specifier (4.3.7).  In
this particular case - (SETF (FIND-CLASS 'GSHARP-PACKAGE:NUMBER)
name of any class, so I think that I'd agree that this should not make
that symbol into a type specifier.  (I doubt if the MOP says anything
that would override this, but I think that the concept of "properly
named" classes was introduced after the MOP was specified and
proposed, and there are some cases where the MOP and CLHS specify
conflicting behavior when the concept of "proper class names" is

> 2. plain DEFTYPE should not do any aliasing for class names
> so for a package that eg. uses STRING as an instance accessor, doing
> something like
> (deftype string () 'cl:string)
> (setf (find-class 'string) (find-class 'cl:string))
> (defgeneric string (x)
> (:method (x)
>    (cl:string x)))
> (defclass thing ()
> ((string :accessor string)))
> would to be the correct way to make 'mypackage:string usable both as
> the second argument to typep, and having (find-class 'mypackage:string)
> return the CL:STRING class.
> DEFCLASS in contrast _is_ defined to make the class name into a type
> specifier, so nuking the old DEFTYPE is definitely correct.

I don't believe that DEFCLASS offers a way of defining a class that's
not properly named, so whether DEFCLASS expands into something that
uses (SETF FIND-CLASS) or uses some other mechanism it's the instant
at which the symbol becomes the proper name of class that that symbol
becomes a type specifier.  At the point when a (proper) class name
becomes a type specifier - shorthand for the class object itself -
it seems clear that other type definitions associated with that name
become invalid, and the implementation may want to make a fuss about

(That isn't, of course, what happens in GSharp's case or in your
example; I think that (SETF FIND-CLASS) does have to check for and
invalidate a conflicting type definition in the case of a
properly-named class, and OpenMCL's behavior in this ("improperly
named") case - which probably predates the concept of properly-named
classes - is incorrect.)

I'd still be surprised if this has much to do with GSharp failing, but
I might be a little less surprised than I was earlier.

More information about the Openmcl-devel mailing list