[Openmcl-devel] Building GSharp (Failure)

Nikodemus Siivola nikodemus at random-state.net
Mon Oct 16 09:21:06 UTC 2006


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
 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 have no
comment of substance on the CERROR/WARNING/just-nuke-it-silenty
behaviour, though as I can't seem to find the bit that talks about
limits on redefinition right now, though I suspect the only
limitations had to do with consistency requirements for compiled code.

> (since it was compiled with the obsolete DEFTYPE in effect.)  CERRORing
> might be an overreaction, but the next most plausible alternative - WARNing -
> often seems like it's saying "It's too late to do anything about it now,
> but you may have just unintentionally screwed things up pretty badly.")

Perhaps that falls more in the realm of package-locks, though?

Cheers,

  -- Nikodemus              Schemer: "Buddha is small, clean, and serious."
                   Lispnik: "Buddha is big, has hairy armpits, and laughs."



More information about the Openmcl-devel mailing list