Subject: Re: weird function behavior
From: Erik Naggum <>
Date: Wed, 15 May 2002 20:59:03 GMT
Newsgroups: comp.lang.lisp
Message-ID: <>

* Jacques Wainer <>
| 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
  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.