[Openmcl-devel] Building GSharp (Failure)
csr21 at cantab.net
Mon Oct 16 09:00:08 UTC 2006
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 126.96.36.199.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
More information about the Openmcl-devel