[Openmcl-devel] Is this a bug?

Gary Byers gb at clozure.com
Sun Mar 16 21:31:58 PDT 2008

On Sun, 16 Mar 2008, Ron Garret wrote:

> On Mar 16, 2008, at 4:21 PM, Gary Byers wrote:
>> The release notes say:
> Ah, yes, those pesky release notes.  I really should bookmark those.
>> Whether that's more trouble than it's worth is another question.
> IMHO it isn't.  I don't see any reason to prevent lexical bindings of
> DEFGLOBALed symbols.  You can lexically bind symbols that are defined
> as symbol macros.  I don't see any justification for making binding of
> DEFGLOBALed symbols any more restrictive than for global symbol macros.


My head hurts.

> I will also make the observation that DEFGLOBAL does not actually
> prevent one from producing code that binds the symbols in question.
> It only prevents one from producing such code after the DEFGLOBAL has
> been evaluated.  This may seem like a pedantic point, but it is
> significant when doing incremental development.  Today I restarted a
> long-running Lisp process only to discover that a whole bunch of code
> that had been working just fine now refused to compile because I had
> written a bunch of code that use the symbol VIEW as an argument, and
> then wrote:
> (defclass view (ns:ns-view)
>   (container)
>   (:metaclass ns:+ns-object))
> rg

DEFCONSTANT and DEFVAR have similar issues, as does conscious,
intentional use of DEFGLOBAL/DEFSTATIC.  (As would redefining
functions as macros or vice versa, etc.)  Code is sensitive to the
environment in which it's compiled.  Defining a class may or may not
be a conscious intentional use of the the class name as a static

I do think that it's probably more trouble than it's worth; I don't
think that it's worth having ObjC class names treated as variables
of any kind, any more than treating CL class names this way would

Note that the release notes entry describing this behavior is about
a year old.  A lot of IDE code and possibly some examples/tutorials
may depend on the idiom (not sure how much), and I don't know how
great the impact of backing out of this would be.

More information about the Openmcl-devel mailing list