Subject: Re: When to recompile/reeval?
From: Erik Naggum <>
Date: 15 Oct 2002 14:47:28 +0000
Newsgroups: comp.lang.lisp
Message-ID: <>

* Peter Seibel
| Does that work even in implementations that don't make much of a
| distinction between compiled and interpreted code. For example, I've been
| using SBCL and was reading something about it the other day that said
| (paraphrasing from memory) that they barely have an interpreter and
| pretty much compile everything all the time.

  You would have to find out if SBCL expands macros too early even when you
  want to run interpreted.  In my view, that is a serious disservice to its
  programmers, when the value of actually working with interpreted code is
  so obvious when you actually need it.  Performance is the key, but Common
  Lisp has generally been willing to consider programmer performance as a
  higher value than code performance in some stages of development.

| [Goes to browse through the HyperSpec].


| Okay, I see " Semantic Constraints" talking about the things that
| you can count on being the *same* between compiled and interpreted
| evaluation; is there somewhere else that talks about required
| *differences*.  Are there any?

  I expect to be able to change a macro definition and its interpreted
  users will reflect the chang while its compiled users would not.

(defmacro macro-expansion-test ()
  (print "I'm being expanded!")
  `(print "I'm the expansion!"))

(defun expanded-when ()

  Evaluate these and see what `(expanded-when)´ produces when you evaluate
  it twice in a row.  If you get the first `print´ while defining it, your
  environment is very eager.  If you get the first `print´ only once, it
  does the expansion on the first evaluation.  I expect it on both.  Then
  `(compile 'expanded-when)´ and it should print "I'm being expanded!" and
  calling it should only produce "I'm the expansion".
Erik Naggum, Oslo, Norway

Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.