CLIM mail archive
[Prev][Next][Index][Thread]

Re: CLIM 2.0, pane names

> From: Kim Barrett <kab@cambridge.apple.com>
> 
> > Whether or not it is prohibited, it is generally unwise to add (most)
> > global attributes to symbols inherited from the common-lisp package,
> > such as a global value, or what is equivalent, a symbol-macro.
> > It stands a good chance of colliding with another program's (possibly
> > accidental) use of that symbol.
> 
> A symbol macro is not a global attribute.  Portable programs cannot make global variable, 
> function, ... definitions for exported CL symbols, but they may establish lexical bindings, 
> where such bindings cannot shadow a defined global binding.
> 
> > Then, there was the time I decided to
> >   (defvar NUMBER <something>)
> > You can go a long time without anything actually _breaking_, before you
> > notice how dumb it is.
> 
> Right.  This code is in error.
> 
> The problem I was responding to however, was that the compiler for some implementation was 
> complaining about valid *lexical* bindings.
> 
> Note however, that it may or may not be that its a bad idea to use exported CL names for 
> these CLIM entities for the same reasons.  I don't know enough about CLIM toknow the scope of 
> the names being defined as CLIM entities.

Kim, since this question originally arose on our implementation, I
should comment.

Under the X3J13 requirements as of the time of CLtL2 it was arguably
illegal for portable code to define a symbol macro on any symbol in
the COMMON-LISP package (p.260).  However, the dpANS explicitly allows
a symbol macro definition on such a symbol that is not globally
defined by the standard to be a variable (section 11.1.2.1.2.1).  I
don't remember whether we at X3J13 actually voted on this change, or
whether it is an editorial clarification that a symbol macro for
purposes of this issue is effectively a lexical binding of the
variable name.  Either way, I personally agree with the dpANS.

Allegro conforms strictly to what CLtL2 said, but we are (of course)
making the change to conform to the dpANS.

Btw, the dpANS still omits at least two obvious restrictions on
portable programs placing global definitions on symbols in the
COMMON-LISP package: Defining a setf expander on a symbol, e.g. with
DEFSETF; and globally defining a setf function, e.g. (SETF CAR).

Reasonable minds could argue whether portable code should use symbols
in the CL package as catch tags and restart names, other than those
restarts already identified by the standard.  The intent of the
standard is to allow placing a lexical definition on a symbol if that
definition doesn't collide with the standard, and to preclude making
any global definitions.  But catch tags and restart names have
_dynamic_ extent, which is somewhere in between.  IMO, the cautious
programmer should avoid them.


0,,
References:
Main Index | Thread Index