From ... Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!news2.kpn.net!news.kpn.net!nslave.kpnqwest.net!nloc.kpnqwest.net!nmaster.kpnqwest.net!nreader2.kpnqwest.net.POSTED!not-for-mail Newsgroups: comp.lang.lisp Subject: Re: Why is Scheme not a Lisp? References: <87pu28kzjy.fsf@charter.net> <87eliokv9v.fsf@charter.net> <87sn73c40c.fsf@charter.net> <873cyzof49.fsf@becket.becket.net> <87sn6zu0wd.fsf@photino.sid.rice.edu> <87henfmz10.fsf@becket.becket.net> <87bsdntyy5.fsf@photino.sid.rice.edu> <87vgbvzkgm.fsf@becket.becket.net> Mail-Copies-To: never From: Erik Naggum Message-ID: <3225356208358354@naggum.net> Organization: Naggum Software, Oslo, Norway Lines: 82 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 17 Mar 2002 12:16:37 GMT X-Complaints-To: newsmaster@KPNQwest.no X-Trace: nreader2.kpnqwest.net 1016367397 193.71.199.50 (Sun, 17 Mar 2002 13:16:37 MET) NNTP-Posting-Date: Sun, 17 Mar 2002 13:16:37 MET Xref: archiver1.google.com comp.lang.lisp:29237 * Thomas Bushnell, BSG | Um, no, nobody wants value lookups to be locked in at read time. Except, | that is, for the one case of "t" and "nil". Those values *are* locked in | at read time, by making those two symbols Very Special. Hey, dude, acquire clue, _then_ talk, will you? Your ability to stop talking when your clue runs out is sorely lacking. This indicates that you talk only to score rhetorical points for yourself, not to discuss anything of value to you or any others. Please latch out of your hostile mode and start to think. You used to be able to think, I remember. This is the real story: t and nil are declared constants, just like pi and most-positive-fixnum. t and nil happen to have themselves as their constant value, but that is quite irrelevant to the binding issue. This has nothing to do with the reader, either. The standard says: The consequences of binding and assigning a constant variable are undefined. The value of a named constant may not be changed by assignment or binding. So this has nothing to do with t or nil being special symbols, it has nothing to do with read-time, it has to do with the rules for binding and assigning constant variables. I wonder why you are not griping about pi, too. Perhaps you are simply unaware of the idea of constant variables? Does Scheme have constant variables? No. It has #f and #t, instead. Does Scheme have a constant value for pi? No. Now, it may illuminate the discussion to see why it is _necessary_ that constant variables not be rebound or assigned to. First, there should be no need for a run-time lookup of their value -- the compiler should be free to inline the value. Like, a test for nil-ness should be no more than a single instruction. So if you change the value of a declared constant (it can be done), you get hosed by the system. Second, to make a constant variable useful to programmers, they must know that they can rely on it. This, somewhat ironically, follows from the _integrated_ macro system in Common Lisp, and it would _not_ follow from the macro bag on the side of Scheme. How do you capture the universal (stronger than global) value of a declared constant when you can shadow the binding and perhaps even make it lexical? What would happen to macro bodies if you could change the value of t or nil? Serious lossage! To be able to rely on your Common Lisp environment, as in trust it, constants _must_ be known to have their one and only constant value. This also means that if it is at all possible that it is not a constant and that you might want to re-bind the value, do not make it a constant. Consequently, ther are few real constants around. pi and e are the mathematical ones with their arbitrary names from a different domain, and t and nil are the boolean ones with their arbitrary names from the Common Lisp domain. That is just how things are. Deal with it. Like it the way it is and spend your mental energy on solving your problems _with_ Common Lisp as a constant as far you are concerned. This part of Common Lisp is not going to be changed. However, if you really, really want to, you can do this: (defpackage "LOSERVILLE" (:use "COMMON-LISP" ...) (:shadow "T")) (defparameter t cl:t) so in Loserville, you may bind t, and most of the time, it will still work. If you want it to work all the time, do not move to Loserville. The magnitude of the confusion and the absence of insight that must exist prior to making such an incredibly bogus claim as "Those values *are* locked in at read time, by making those two symbols Very Special" is just _staggering_. The cluelessness that this betrays is so fantastically destructive to your credibility that it approaches the idiocy you keep committing when you post lies about what I would do just because you need to feed your psychotic imagination. You know just about as much about Common Lisp as you do about me, and you have _no_ control over your blabbering. It is _fantastically_ annoying to have people like you around. Go away! | That's the problem. It's a teeny problem (and it wasn't I that brought | it up), but it's a problem. It's forced upon CL by compatibility | considerations, and that's a perfectly good reason for CL to maintain the | historic practice. But it doesn't make the historic practice right. Do you have the mental capacity to back down when you are wrong? /// -- In a fight against something, the fight has value, victory has none. In a fight for something, the fight is a loss, victory merely relief.