R5Rs 4.3.2 says that "Identifiers that appear in the template but are not pattern variables or the identifier ... are inserted into the output as literal identifiers. If a literal identifier is inserted as a free identifier then it refers to the binding of that identifier within whose scope the instance of syntax-rules appears. If a literal identifier is inserted as a bound identifier then it is in effect renamed to prevent inadvertent captures of free identifiers."
Your "foo" is thus a literal identifier, and the behavior depends on whether top-level define is a binding construct. Note that Section 5.2.1 is carefully ambiguous about whether top-level define establishes a new binding. It is not required to, or is it required to behave the same way for every variable (it is permitted for it to establish bindings sometimes but not others). So this is not a bug. The define is a top-level define, which is being done in the way 5.2.1 permits, with the binding established *before* the define ever runs, and the define itself being equivalent to set!. And then, the syntax-rules template is dealing with a free literal identifier, and the expanded macro thus refers to the enclosing (global) binding. Thomas On Tue, 2009-07-28 at 02:33 -0400, John Cowan wrote: > jco...@jcowan-laptop:~$ rlwrap csi > > CHICKEN > (c)2008-2009 The Chicken Team > (c)2000-2007 Felix L. Winkelmann > Version 4.1.1 - SVN rev. 15267 > linux-unix-gnu-x86 [ manyargs dload ptables applyhook ] > compiled 2009-07-26 on jcowan-laptop (Linux) > > #;1> (define-syntax Foo (syntax-rules () ((Foo) (define foo 1)))) > #;2> (Foo) > #;3> foo > 1 > #;4> > > The name "foo" is introduced inside a hygienic macro, and should not > be visible outside the macro. This bug does not manifest for internal > defines within macros. > _______________________________________________ Chicken-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/chicken-users
