chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] Macros that return defines are non-hygienic


From: Thomas Bushnell BSG
Subject: Re: [Chicken-users] Macros that return defines are non-hygienic
Date: Tue, 28 Jul 2009 10:36:43 -0700

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:
> address@hidden:~$ 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.
> 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]