[Top][All Lists]

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

Re: [Chicken-users] Bug report: low-level macros vs. variables in csi

From: John Cowan
Subject: Re: [Chicken-users] Bug report: low-level macros vs. variables in csi
Date: Sat, 15 Mar 2008 23:04:11 -0400
User-agent: Mutt/1.5.13 (2006-08-11)

Jim Ursetto scripsit:

> If this behavior is causing you problems, and you can't work around it, I
> believe you could use the codewalk egg with your own (nonhygienic)
> macroexpander to keep track of the latest binding for an identifier and
> select the correct one, even taking into account lexical shadowing (which
> you did not mention).  Check the modules egg for an example, and also the
> branches/define-macro branch for a version that deals with macros.

It's not that it "causes problems", it's that it's surprising and can
interfere with debugging.  Presumably no one *wants* to define a macro and
a Scheme identifier using the same name, but it can happen by accident,
and although csc will complain, csi will not.

> For what it's worth, the following already does the "right thing"
> in the interpreter.
> $ csi
> #;1> (let ((cond 43)) (cond (#t cond)))
> Error: call of non-procedure: #t

Good point.  So that makes the fix very simple: whenever a macro
is defined by define-macro, set the global value of the corresponding
Scheme identifier to undefined; and ensure that all the built-in macros
and special operators are already set that way.

Likewise, when the global value of an identifier is set, remove any
macro definition.  (That might leave you screwed if you redefine "cond",
but that's what you asked for, if not what you wanted.)

Verbogeny is one of the pleasurettes    John Cowan <address@hidden>
of a creatific thinkerizer.   
   -- Peter da Silva

reply via email to

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