Re: CLIM 2.0, pane names

• To: clim@BBN.COM
• Subject: Re: CLIM 2.0, pane names
• From: "Bruce R. Miller" <miller@cam.nist.gov>
• Date: Wed, 9 Dec 1992 14:22-0500
• In-Reply-To: <9212091841.AA28654@cambridge.apple.com>

    Date: Wed, 9 Dec 1992 13:43 EST
    From: Kim Barrett <kab@cambridge.apple.com>

    > 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)?

    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.

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.

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.

  bruce
  miller@cam.nist.gov
  

0,,

• Re: CLIM 2.0, pane names
• From: Kim Barrett <kab@cambridge.apple.com>

• Prev: Re: CLIM 2.0, pane names
• 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)