Subject: Re: weird function behavior From: Erik Naggum <erik@naggum.net> Date: Wed, 15 May 2002 20:59:03 GMT Newsgroups: comp.lang.lisp Message-ID: <3230485142957966@naggum.net> * Jacques Wainer <wainer@ic.unicamp.br> | no where there is any indication that '(nil) is a constant. Yes, there is. It is right there in the specification. It also follows from other things you ought know about Common Lisp. | The fact that the complier/evaluator considers that a constant to me is a | bad design decision. A more irrelevant "argument" could probably not be constructed. | In fact, I could accept that the compiler, with optimization set to a | high level, would implement '(nil) as a constant but I would not expect | the evaluator in clisp, to perform such optimization. This is how it works: 1 The Common Lisp reader is responsible for constructing the in-memory lists that make up the source program. Thus, (quote (nil)) is the actual source code. 2 The quote special operator returns its unevaluated argument. Thus, the (nil) is still the actual source code. 3 (elt x 0) refers to the car of one of the cons cells that make up the actual source code. 4 Changing the car of a cons cell that the actual source code is made up of _obviously_ affects the source code for the interpreter. 5 Common Lisp is based in the premise that the programmer knows what he is doing, so if the programmer does the above, it is because he means it. 6 Because compiled and interpreted code in Common Lisp are required to have identical semantics (meaning and behavior), the compiler has to preserve this property of quoted objects, i.e., objects produced by the Common Lisp reader. 7 This is not an optimization. An optimization would be to make two _different_ '(nil) be the same. This does not happen here. | Before this event, I thought '(nil) to be operationally equivalent to | (list nil), but just notationally more convenient. In Common Lisp, it is vitally important to understand when objects are constructed and when forms are evaluated. There are four times that you should be aware of: A read-time. The Common Lisp reader builds the object when reading the source code and the compiler arranges for the object to be re-created when loading a compiled file. Obtained with the special operator quote. The read macro #. also causes evaluation of expression to occur in the reader and the resulting value to be returned. B load-time. The Common Lisp loader builds the object either in order to preserve a read-time object creation, or as obtained with the special operator load-time-value. (This used to be the read macro #, -- which I have a hard time understanding why was not just turned into a short-hand for load-time-value.) Also controlled by eval-when :load-toplevel, or, more appropriately, excluding :load-toplevel from eval-when makes it not happen at load-time, because that is the default. C compile-time. The file compiler normally only reads source code and produces a binary file that arranges for the loader to produce the same effects as it would have if it loaded the source code, and does not evaluate the code it so compiles, unless eval-when :compile-toplevel is used to instruct the compiler to evaluate it. Several macros do this. (I mention this and eval-when because you will run into a similar kind of problem sooner or later. Then you will remember this, because you are annoyed by something you do not understand that bit you, now, too.) D run-time. The "normal" execution time that programmers want to control. At this time, it is much more important for you to understand that not everything happens at run-time than exactly what happens at run-time. I hope this helps. My patience with people who think their ignorance gives them the right to denigrate design decisions they do not understand is _extremely_ short. If you do not accept that the above is offered in the best interest of helping you understand something you previously did not, but come back with more negative and ignorant arroganceb about the design, you will only piss people off, and I will get seriously annoyed for having wasted my time on yet another unworthy person. Most of us here would like to help people understand Common Lisp, but before you understand, you listen. It is vital to successful learning that you do not jump to conclusions and accept that you do not understand or know something and do not have the right to even _have_ opinions on design decisions until you know what they are. Most of the time, people who know little and speak much make fools of themselves and piss people off, and I have tended to express my strong desire to send these people to hell on the first shuttle out of here, but I shall make an attempt to delay that and ask you to think things through and try to avoid annoying people by believing that you know something you do not but which is a requirement for the opinions you think you have a right to have. You do not have to agree with what I have told you, but you have to listen and study and make a visible effort to understand before you argue against it. This is how things work. In time, you will be the one giving this lecture. -- 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. 70 percent of American adults do not understand the scientific process.