[Openmcl-devel] Building GSharp (Failure)

[Christophe Rhodes]

Gary Byers <gb at clozure.com> writes:

> I checked out the current gsharp sources from CVS.  In that version,
> in the file "packages.lisp", it does:
>
> (in-package :gsharp-numbering) ; this package inherits a shadowed
>                                 ; symbol named "NUMBER"
> (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.  

Agreed.  (I wrote this code originally).  Is it clear that 
  (setf (find-class <name>) <class>)

has the side-effect of registering <name> in the type system?  It
wasn't to me when I wrote the code, but I could have missed something.
(It happens to in SBCL as well, but I think that has changed several
times over the years).

> (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.)

GSharp defines a function called NUMBER, which can't live in the CL
package because of the restrictions on programs in CLHS 11.1.2.1.2.

>> If I allow it to run (via a :GO command) the program compiles but
>> doesn't seem functional.
>
> Fascinating as all of the above may (or may not) be, it's not clear how
> that (CERRORing on a certain kind of type redefinition) could have had
> any effect - negative or otherwise - on functionality.

I agree with this analysis, and indeed largely with the "general case"
analysis that I have elided.  If gsharp is not working, it is for a
different reason.

Cheers,

Christophe