From ... From: Erik Naggum Subject: Re: compiling cmulisp Date: 1998/10/24 Message-ID: <3118220356746280@naggum.no>#1/1 X-Deja-AN: 404583921 References: <87ogrr1mkj.fsf@ivm.de> <361CA1D6.257FDA18@saturn.math.uaa.alaska.edu> <361f7b71.345757462@news.newsguy.com> <361eab3a.423526288@news.newsguy.com> <6vokh0$d06$1@counter.bik-gmbh.de> <362017d0.10619730@news.newsguy.com> <6vras6$5ah$1@counter.bik-gmbh.de> <36228edb.70281529@news.newsguy.com> <6vvkhb$cpq$1@counter.bik-gmbh.de> <3624f48f.78896787@news.newsguy.com> <4ng1cr1h3g.fsf@rtp.ericsson.se> mail-copies-to: never Organization: Naggum Software; +47 8800 8879; http://www.naggum.no Newsgroups: comp.lang.lisp * Raymond Toy | However, with CMUCL, recompiling the compiler *changes* the compiler | that's doing the compiling. For example, there's a variable in CMUCL | that essentially is an enum for all of the recognized types. If you add | a new type, such as (signed-byte 8), this needs to be placed in the enum. | However, when you compile this up, it changes that variable in the | compiler that's compiling the code, and the current compiler is totally | confused by that change because it's now wrong. this can't be true. COMPILE-FILE is explicitly required _not_ to pollute the execution environment, but (in some sense) write compiled code to a file for later loading. only if you cause expressions to be avaluated at compile-time should this affect the execution environment. I don't think anyone could reasonably be expected to do that with a variable if it has the effect you sketch; it's a (fixable) bug, not an inherent problem. (sorry for the belated response, ignore if no longer relevant.) #:Erik -- The Microsoft Dating Program -- where do you want to crash tonight?