>>>> "Craig" == Craig Lanning
<CraigL(a)internetx.net> writes:
Craig> At 10:01 AM 8/17/98 +0200, Michael Sperber [Mr. Preprocessor] wrote:
> This indeed shows the CONS example to be poor. The point remains
the
> same, however: What if we bind a variable bound in a macro. Say,
> *features*? What if a temporary identifier in a macro definition
> shadows a binding in a use?
Craig> I think I see what you're driving at, but I'm not sure that it's as
Craig> important as it's being made out to be. It's easy enough to use
Craig> MAKE-SYMBOL to create safe variable names for the macro and still
Craig> maintain readability.
Sure, but there's no guarantee that a given macro has hygienic
behavior. Generally, maintaining hygiene this way is pretty tedious,
which is why programmers usually don't go to the necessary lengths.
Also, a macro might refer to bindings whose names are free in the
macro definition. There's no guarantee that you'll get the same
bindings for a use that you referred to at the point of definition.
Craig> It's also easy enough to expand (via MACROEXPAND)
Craig> the macro to see what it will look like (Zmacs will let me do this with
Craig> control-shift-M and meta-shift-M).
This severely restricts the complexity of macros I can use safely.
Also, the whole point of macros is syntactic abstraction. I don't
want to have to expand it to see if it does something evil.
> In the examples, I don't *need* to use CONS, it just might
happen to
> be a convenient name.
Craig> Expanding the macro should tell you everything that you need to know.
As I said, having to expand the macro is totally counterproductive.
The great thing about Scheme macros is that I basically never have to
do this. I certainly never have to do it in order to check hygiene.
(Moreover, expanding the macros cannot tell two uninterned symbols
with the same name apart, can it?)
> What I would also want is, that, if a macro is defined within a
> certain package, and I refer to bindings from the macro, that these
> bindings are relative to the package of definition rather than the
> package of use, obeying the standard rules of lexical scoping. Not
> having this (as in CL) introduces other dangers.
Craig> I'm not sure what "bindings from the macro" you are referring to.
Craig> All symbols in the macro definition are relative to the package of
Craig> definition and not the package of use. I depend on this for my most
Craig> common use of macros.
Sorry, I should have been more specific. Here's an example not even
involving explicit packages:
Let's say I have this:
(defvar bar 23)
and I want to refer to bar (that is, the above binding) in a macro
body:
(defmacro foo () 'bar)
... but I do:
(let ((bar 42)) (foo))
=> 42
This violates lexical scoping.
--
Cheers =8-} Chipsy
Friede, Völkerverständigung und überhaupt blabla