Re: [spr4745] Interaction between flet and macrolet

[smh@franz.com (Steve Haflich)]

[This matter has been assigned the tracking identifier "spr4745".
Please refer to it in any followup communication.]

   From: edward@homer.cs.berkeley.edu (Edward Wang)

   Is a local macro (defined using macrolet) allowed to use
   a local function (defined using flet) in the surrounding
   lexical environment?  For example,

   (defun x ()
     (flet ((y (n) (1+ n)))
       (macrolet ((z (n) (y n)))
	 (z 1))))

Te behavior of this code is explicitly undefined.  Check the last
change bar on CLtL2 p.153:

     [T]he macro-expansoin functions created by macrolet are defined in the
     lexical environment in which the macrolet form appears ...
     Declarations, macrolet definitions, and symbol-macrolet definitions
     affect code within the expansion functions in a macrolet, but the
     consequences are undefined if such code attempts to refer to any local
     variable of function bindings that are visible in that environment."

Therefore your reference to an outer flet isn't defined.  It would be
well defined, however, if the flet were lexically inside the macrolet.

   Now, cl version 4.0 gives an error (y not defined) when
   x is called.  Version 4.1beta returns 2 when (x) is interpreted,
   but core dumps when during compilation of x.

   Which is the correct behavior?

Well, all of them are correct because the behavior isn't undefined.
(The post-beta 4.1 infinite loops.)  Of course, neither looping nor
crashing are particularly good behavior, so I'll file a bug to catch
the bad code more elegantly.

   While I'm at it, when will 4.1 be ready, and will it have
   the functions dealing with syntactic environments
   (variable-information, augment-environment, etc.)?

4.1. is still some weeks away -- I don't have an exact date.  The
syntactic environment access functions may never be implemented
because X3J13 removed them from the language definition subsequent to
the publication of CLtL2, removing essentially all of CLtL2 section
8.5.  The design was flawed, and it was essentially impossible to fix
the problems without extensive changes elsewhere in the language.
Offhand I don't remember further specifics, except that most people
felt that it would be a good idea for implementations to try to proved
these capabilities as extensions, even if flawed.  We may do so
someday, but there is no schedule.