Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

What if a compiler macro function returns nil?

2 views
Skip to first unread message

Kalle Niemitalo

unread,
Sep 20, 1999, 3:00:00 AM9/20/99
to
In the Common Lisp HyperSpec section 3.2.2.1 Compiler Macros:
# The return value from the expansion function, which is passed
# through by the macroexpand hook, might either be the same form,
# or else a form that can, at the discretion of the code doing
# the expansion, be used in place of the original form.

But in the Glossary:
# compiler macro function n. a function of two arguments, a form
# and an environment, that implements compiler macro expansion by
# producing either a form to be used in place of the original
# argument form or else nil, indicating that the original form
# should not be replaced. See Section 3.2.2.1 (Compiler Macros).

Is returning nil then equivalent to returning the original form?

Antonio Leitao

unread,
Sep 20, 1999, 3:00:00 AM9/20/99
to
>>>>> "Kalle" == Kalle Niemitalo <to...@stekt.oulu.fi> writes:

Kalle> In the Common Lisp HyperSpec section 3.2.2.1 Compiler Macros:
Kalle> # The return value from the expansion function, which is passed
Kalle> # through by the macroexpand hook, might either be the same form,
Kalle> # or else a form that can, at the discretion of the code doing
Kalle> # the expansion, be used in place of the original form.

Kalle> But in the Glossary:
Kalle> # compiler macro function n. a function of two arguments, a form
Kalle> # and an environment, that implements compiler macro expansion by
Kalle> # producing either a form to be used in place of the original
Kalle> # argument form or else nil, indicating that the original form
Kalle> # should not be replaced. See Section 3.2.2.1 (Compiler Macros).

Kalle> Is returning nil then equivalent to returning the original form?

If I remember correctly, it's a bug in the glossary.

For the compiler macro to indicate that the original form should not
be replaced, it must return the original form (eql, not equal), which
means you must use &whole in the parameter list to get access to it.

Hope this helps,

Antonio.

Kent M Pitman

unread,
Sep 20, 1999, 3:00:00 AM9/20/99
to
Kalle Niemitalo <to...@stekt.oulu.fi> writes:

>
> In the Common Lisp HyperSpec section 3.2.2.1 Compiler Macros:

> # The return value from the expansion function, which is passed

> # through by the macroexpand hook, might either be the same form,

> # or else a form that can, at the discretion of the code doing

> # the expansion, be used in place of the original form.
>

> But in the Glossary:


> # compiler macro function n. a function of two arguments, a form

> # and an environment, that implements compiler macro expansion by

> # producing either a form to be used in place of the original

> # argument form or else nil, indicating that the original form

> # should not be replaced. See Section 3.2.2.1 (Compiler Macros).
>

> Is returning nil then equivalent to returning the original form?

I think it's something that needs to be clarified.

It's easy to program in a way that treats this conservatively,
expanding to (quote nil) if you want nil as an expansion, and I
recommend doing so.

Vendors are in a harder position, but I personally think they should
accept either NIL or the form as meaning "don't expand".

I think the original intent was to accept the original form as a
"don't expand", but original intent is not particularly relevant
since it is nowhere specifically documented.

0 new messages