Re: Equivalent of C's "global/static" variables

Duane,

Very informative, thanks! A few points:

In article <o07j8yohqs.fsf@xxxxxxxxx>, Duane Rettig <duane@xxxxxxxxx> wrote:
> > CMUCL at least says
> > "#<Interpreted Function UPDATE {480245C1}> was defined in a non-null
> > environment."
>
> This message, however, suggests a bug in CMUCL - whereas is perfectly
> reasonable to decide not to compile the lexical closure for update in
> the particular non-null lexical environment it was given, the spec
> is more careful about how it states where the undefined behavior starts
> and ends; what it actually says, in teh descriptuon for COMPILE, is:
>
> "The consequences are undefined if the lexical environment
> surrounding the function to be compiled contains any bindings
> other than those for macros, symbol macros, or declarations."
>
> So in fact, something like:
>
> (macrolet ((foo (x) `(car ,x)))
> (defun bar (y) (foo y)))
>
> ...
>
> (compile 'bar)
>
> should in fact work. Perhaps they've fixed it now, but the versions
> of cmucl I try out from time to time don't handle this; apparently
> they refuse to compile any interpreted function within a non-null
> lexical environment (which is not what the spec allows). Perhaps
> there should have been a glossary term such as "trivial lexical
> environment" to cover a lexical environment which is non-null, but
> has no lexical definitons other than macros, symbol-macros, or
> declarations - then an error message like "... was defined in a
> non-trivial lexical environment." would have been an easy and well-defined
> error message...

Agreed, and I think I got this right in SBCL's evaluator (due to be
finished and integrated into mainline well before the year 2038):

* (macrolet ((foo (x) `(car ,x)))
(defun bar (y) (foo y)))
BAR
* (compile 'bar)
BAR
NIL
NIL

* (let ((x 4))
(defun set-x (v) (setf x v))
(defun get-x () x))
GET-X
* (compile 'get-x)
debugger invoked on a SB-EVAL::ENVIRONMENT-TOO-COMPLEX-ERROR in thread 313:
Lexical environment of #<INTERPRETED-FUNCTION GET-X> is too complex to
compile.

> [*] Compilation of definitions within the original form clearly has
> undefined consequences, so this part of the discussion deals with
> parts over and above the spec. I agree that the error message that
> Allegro CL gives is not helpful. However, if there had not been a
> bug in the way Allegro CL extends the spec to try to make some sense
> out of calling compile on these definitions, then you would not have
> gotten any error at all, but would have instead gotten a compiled
> functon which would have done the intuitively correct thing. We're
> able to consider doing this because of the similarity between the
> representations of compiled and interpreted environments in our
> implementation.

> It is unfortunate that you selected 'update to compile, since that
> one demonstrates the bug. The bug is that we rewrite the accesses
> to each variable as locally forms, and they do not expand well
> in setf situations. I will be working on fixing that, probably for
> future releases, but fortunately I can show you how it _does_ work
> in situations where setf is not involved, and in fact the code
> is already provided (we just compile the other function!):

I must say I'm very impressed you can make this work even some of the
time! Thinking about how to make this work in the above SBCL evaluator
generally gave me a headache, and after seeing every other implementation
I tried not do it either (and reading in the spec that it's undefined),
I decided to punt. It's doubly unfortunate that in all the cases I've
tried it on ACL I've stumbled across this bug.

-bcd
--
*** Brian Downing <bdowning at lavos dot net>
.

Relevant Pages

  • Re: ERROR: JDWP Unable to get JNI 1.2 environment?
    ... compile and run without error): ... JDWP Unable to get JNI 1.2 environment, ... It's been reported as a bug too: ...
    (comp.lang.java.programmer)
  • Evaluating/compiling forms in the current lexical environment.
    ... it's not possible EVAL or COMPILE forms within a lexical environment of one's ... EVAL is not implemented through COMPILE, usually has an environment, and one ... (defpackage lexical-eval/compile ... "Obtain a list of names of the local lexical variables in the ENV ...
    (comp.lang.lisp)
  • Re: A short-but-bizarre program that shouldnt work but does.
    ... According to the C Standard, as I interpret it, this should ... either won't compile, ... It's called a "Common extension". ... J.5.1 Environment arguments ...
    (comp.lang.c)
  • RE: DBI connect(,/,...) failed: ERROR OCIEnvInit
    ... Are you changing your environment between the two connects? ... Andy Hassall / Space: ... > When making a connection to an 8i instance, ... > Do I need to compile specifically against the 9i libraries to ...
    (perl.dbi.users)
  • Re: Foreign Function Interfaces
    ... Note, however, that it's pretty hard to impossible anyway to do decent compilation once you introduce first-class lexical environments. ... Lookup of variables has to go through an environment structure and this is slower than lexical addressing. ... Due to macros, a capture of a lexical environment can happen almost anywhere. ...
    (comp.lang.lisp)