Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!bu-cs!purdue!decwrl!sun!pitstop!sundc!seismo!uunet!mcvax!ukc!etive!aipna!jeff
From: jeff@aipna.ed.ac.uk (Jeff Dalton)
Newsgroups: comp.lang.lisp
Subject: Re: Common Lisp Problems with Hash-table in Macros
Message-ID: <405@aipna.ed.ac.uk>
Date: 16 Dec 88 17:07:33 GMT
References: <698@crin.crin.fr> <290@nvuxh.UUCP>
Reply-To: jeff@uk.ac.ed.aipna.UUCP (Jeff Dalton)
Organization: Dept. of AI, Edinburgh, UK
Lines: 26

In article <290@nvuxh.UUCP> hall%nvuxh.UUCP@bellcore.COM (Michael R Hall) writes:
>The example works fine, both interpreted and compiled, in Sun
>(Lucid) Common Lisp version 3.4.  The problem, therefore, is KCL. 

That isn't necessarily so.  This is an area in which different
Common Lisps differ and also one that is not well-defined by 
CLtL.  Besides, it is not true, in general, that when two
Common Lisp agree they are necessarily right.  KCL tends to
be a fairly minimal Common Lisp, in that it doesn't do much
beyond what's explicitly said in CLtL, and was developed by
people who knew less of the "shared cultural background"
that informs many American Common Lisps.  (For example, Mac
Lisp stored compiled constants in non-printed form, but I
don't think anything in CLtL says that is necessary.) So KCL
sometimes differs without necessarily being wrong.

>Many Common Lisp implementations have buggy lexical closures,
>especially compiled.  I don't know why, since they're not all that
>hard to implement.  I suspect the KCL compiler cannot generate proper
>lexical closure code, even though the lexical closure in question
>references no variables outside its body.  

As far as I can tell, KCL can compile code with #'(lambda ...) in
it.  Besides, I know the problem is due to something else, as
explained in an earlier message.  Your suspicion was a reasonable
one but happens to be wrong as far as KCL is concerned.