Re: Opinions wanted: What should (.list pmacro-name 42) do?

[Jim Blandy <jimb@red-bean.com>]

On Thu, Aug 20, 2009 at 10:30 AM, Doug Evans<dje@sebabeach.org> wrote:
> Hi.
>
> What should the output of
>
> (define-pmacro (foo a) (add a 1))
> (.list foo 42)
>
> be?
>
> Currently the result is (<pmacro> 42)
> where <pmacro> is the pmacro object for "foo".
>
> It's not ideal because it means that a pmacro object "escapes"
> pmacro-processing and can be seen by, for example, rtl compilation.
>
> However, it's not that unexpected.  The user asked for a list containing two
> objects, the pmacro and 42.
> This is akin to saying (list + 42) in Scheme.
>
> We *could* have the pmacro evaluator re-examine the result and if it sees
> (<pmacro> mumble) then re-expand it.  That's what we do for symbols today
> (i.e. if the result of pmacro-expansion is a symbol that names a pmacro, we
> re-evaluate it), but that has problems, e.g.
> http://sourceware.org/ml/cgen/2009-q3/msg00052.html
> and I'm leaning toward removing that behavior.

Macros should definitely be able to expand to calls to other macros
somehow; doesn't (.list 'foo 42) do this?  If it does, then I don't
see much point in allowing (.list foo 42) to do so as well.  The
source world and the value world need to interact only in
easy-to-reason-about ways, or you end up with stuff like m4, which is
just chaos.

This reminds me of the "3-d macro" problem in Scheme, where macros can
place values that can't actually be written in Scheme source code
(procedure objects, say) into the tree that the compiler eventually
sees.  I've always thought the cleanest thing was to reject such code,
as it didn't seem useful, and made a weird breach between macro
expansion time and run time.