From: mike...@mikemac.com (Mike McDonald) Subject: Re: `fast' global variables (Ex: Re: ??: using * for variable ?) Date: 1999/03/23 Message-ID: <7d8uim$itl$1@spitting-spider.aracnet.com>#1/1 X-Deja-AN: 458104435 References: <7csm6k$31f$1@nnrp1.dejanews.com> <36F31455.35F0CCB4@IntelliMarket.Com> <7d4165$acl$1@nnrp1.dejanews.com> <36F66BFC.A7EA65D7@elwood.com> <7d6dtj$bp0$1@nnrp1.dejanews.com> <7d6fdb$egv$1@spitting-spider.aracnet.com> <3131135071149992@naggum.no> <7d6pos$h6f$1@spitting-spider.aracnet.com> <3131171314435096@naggum.no> <7d8h8q$f53$1@spitting-spider.aracnet.com> Content-Type: text/plain; charset=us-ascii Organization: aracnet.com Mime-Version: 1.0 Reply-To: mike...@mikemac.com Newsgroups: comp.lang.lisp In article , Tim Bradshaw writes: > mike...@mikemac.com (Mike McDonald) writes: > > >> The part where you're adding the immutable to it. At least in the hyper >> spec's glossary, which you quoted, it does NOT say literal objects are >> immutable. A literal object is that one, unique object. It says nothing about >> the status of its contents. In their example of '("two"), it's the cons cell >> that is the literal object being refered to, not the string "two" or the NIL >> on the end. Granted, in this example, you'd confuse most people by replaca-ing >> the list, but I don't see anything in this definition that it says you can't. > > I think that a quoted list like that *is* immutable in fact. Could be (and probably shoould be although I've never seen an immutable cons cell before). But that's a separate issue from what a "literal" is. > I am surprised that the value of something defined with DEFCONSTANT is > immutable, though that seems to be a plausible reading of the spec Well you should be surprised since no one has been able to show that the spec says that. > (and I can kind of see why it should be like that, because of all the > issues with compileload/runtime sameness. That's a different issue. What it means is that if in one file I have (defconstant *foo* (make-array 10)) (defun baz () (print (eql *foo* (bar)))) and in another file I have (defun bar () *foo*) then what gets printed out when BAZ is called can be either T or NIL. (Because the *foo* in BAR may have gotten the value from a different environment. Now, if you had used DEFVAR instead, it'd always print the expected T. Kind of counter intuitive that DEFVAR's are EQ but DEFCONSTANTs aren't necessarily.) > how hard would it be to make > DEFCONSTANT do (what I think is) the right thing? > > --tim I contend the spec already says it does work that way. Mike McDonald mike...@mikemac.com