macrolet environment issue

Bug #309460 reported by Nikodemus Siivola
2
Affects Status Importance Assigned to Milestone
SBCL
Confirmed
Low
Unassigned

Bug Description

   As of version 0.pre7.14, SBCL's implementation of MACROLET makes
   the entire lexical environment at the point of MACROLET available
   in the bodies of the macroexpander functions. In particular, it
   allows the function bodies (which run at compile time) to try to
   access lexical variables (which are only defined at runtime).
   It doesn't even issue a warning, which is bad.

   The SBCL behavior arguably conforms to the ANSI spec (since the
   spec says that the behavior is undefined, ergo anything conforms).
   However, it would be better to issue a compile-time error.
   Unfortunately I (WHN) don't see any simple way to detect this
   condition in order to issue such an error, so for the meantime
   SBCL just does this weird broken "conforming" thing.

   The ANSI standard says, in the definition of the special operator
   MACROLET,
       The macro-expansion functions defined by MACROLET are defined
       in the lexical environment in which the MACROLET form appears.
       Declarations and MACROLET and SYMBOL-MACROLET definitions affect
       the local macro definitions in a MACROLET, but the consequences
       are undefined if the local macro definitions reference any
       local variable or function bindings that are visible in that
       lexical environment.
   Then it seems to contradict itself by giving the example
 (defun foo (x flag)
    (macrolet ((fudge (z)
                  ;The parameters x and flag are not accessible
                  ; at this point; a reference to flag would be to
                  ; the global variable of that name.
                  ` (if flag (* ,z ,z) ,z)))
     ;The parameters x and flag are accessible here.
      (+ x
         (fudge x)
         (fudge (+ x 1)))))
   The comment "a reference to flag would be to the global variable
   of the same name" sounds like good behavior for the system to have.
   but actual specification quoted above says that the actual behavior
   is undefined.

   (Since 0.7.8.23 macroexpanders are defined in a restricted version
   of the lexical environment, containing no lexical variables and
   functions, which seems to conform to ANSI and CLtL2, but signalling
   a STYLE-WARNING for references to variables similar to locals might
   be a good thing.)

Revision history for this message
Nikodemus Siivola (nikodemus) wrote :

My brain hurts. Still, as the bug really just asks to "make an interpretation, document it, and stick to it" -- this is clearly something that should be done.

Changed in sbcl:
importance: Undecided → Low
status: New → Confirmed
Revision history for this message
Nikodemus Siivola (nikodemus) wrote :

See also bug 309123.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.