Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!nrl-cmf!ukma!rutgers!att!ulysses!gamma!pyuxp!nvuxj!nvuxl!nvuxh!hall
From: hall@nvuxh.UUCP (Michael R Hall)
Newsgroups: comp.lang.lisp
Subject: Re: Common Lisp Problems with Hash-table in Macros
Summary: Lexical closures may be buggy
Message-ID: <290@nvuxh.UUCP>
Date: 13 Dec 88 01:12:19 GMT
References: <698@crin.crin.fr>
Reply-To: hall%nvuxh.UUCP@bellcore.COM (Michael R Hall)
Organization: Bell Communications Research
Lines: 26

In article <698@crin.crin.fr> stephan@crin.crin.fr (Stephan BRUNESSAUX) writes:
>Is there anybody out there who can explain me what is wrong with
>this example which correctly runs in both interpreted and compiled mode on
>Symbolics 3620 (Genera 7.2) and correctly ONLY in interpreted mode on TI 
>Explorer II and on VAX running KCL (June 3, 1987) but not in compiled 
>mode !?... [Example omitted]

The example works fine, both interpreted and compiled, in Sun
(Lucid) Common Lisp version 3.4.  The problem, therefore, is KCL. 
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.  The first example
uses #'print, which works fine in KCL; the second example uses
#'(lambda (key val) [body omitted]) and the KCL compiler barfs.  I
suggest defining a function like this
   (defun foo (key val) [body omitted])
and then referencing it as #'foo.
This, of course, should not make a difference, but it may make all
the difference to a buggy version of Common Lisp.

If all else fails, simply leave part of the code uncompiled.
-- 
Michael R. Hall              |"I live in a country that I hate.  I live in a
hall%nvuxh.UUCP@bellcore.COM | country where I want to shoot the politicians."
bellcore!nvuxh!hall          | - Peter Buck of R.E.M.