Re: CLIM 2.0, pane names

• To: Andrew Philpot <philpot@ptolemy.arc.nasa.gov>
• Subject: Re: CLIM 2.0, pane names
• From: Kim Barrett <kab@cambridge.apple.com>
• Date: Wed, 09 Dec 92 13:43:36
• Cc: clim@BBN.COM

> The messages my compiler is
> emitting seem to indicate this, though.  The following bit of code
> causes a warning that the code is non-portable because it used the
> symbol CL:TRACE (inherited) as a pane name.  It appears that pane
> names are being turned into symbol-macros via SYMBOL-MACROLET and it's
> wrong for portable code to make symbol-macro definitions with the same
> name as CL base symbols.
> 
> Is it the intent for users to have to carefully cull out lots of
> useful symbols like CONDITION, WARNING, DRIBBLE, TRACE, TYPE, CLASS,
> EXPORT, FUNCTION, CONSTANTLY :-) as pane names because of this
> conflict> If so, I guess the documentation should make this explicit.
> 
> Or is it the case that the compiler is overly anxious here (since it
> would be hard for a symbol-macro to interfere with any of the
> semantics of these symbols)?
>
> ;; --------------- replay of warning message ---------------
> 
> Warning: Compiling a SYMBOL-MACROLET definition for the name TRACE.
> This name is in the COMMON-LISP package and defining it will be a
> violation for portable programs.  The package COMMON-LISP has
> EXCL:PACKAGE-DEFINITION-LOCK set, which causes the system to check for
> this violation. 

I would say that the compiler is being overly anxious.  Since these symbols are not 
defined by the language specification as variables, implementations are prohibited from 
defining them as variables, and portable programs are permitted to lexically bind them 
as variables.  See X3J13 issues LISP-SYMBOL-REDEFINITION and PACKAGE-CLUTTER.

0,,

• Re: CLIM 2.0, pane names
• From: "Bruce R. Miller" <miller@cam.nist.gov>

• Prev: Drawing Order
• Next: Re: CLIM 2.0, pane names
• Index: CLIM Mailing list (1-Sep-92 to 31-Dec-92)
• Thread: CLIM Mailing list Index (1-Sep-92 to 31-Dec-92)