[Top][All Lists]

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

Re: moving more cl seq/mapping support into core

From: Christian Ohler
Subject: Re: moving more cl seq/mapping support into core
Date: Fri, 08 Oct 2010 12:45:24 +0930

 On 8/10/10 11:48, Miles Bader wrote:
Christian Ohler<address@hidden>  writes:
: If cl.el is loaded, ERT needs to pass two arguments to
macroexpand', only one otherwise.  The solution is simple, but
figuring out that this problem exists took me a while.
The normal (non-cl) macroexpand takes the same arguments, so why do
you need to make a distinction?

It takes an environment argument, but I don't know where to get an environment value if cl.el is not loaded. Originally, I defined my macros with defmacro* and &environment, but such macros can only be expanded when cl.el is loaded, since their definition references `cl-macro-environment', which is only bound with cl.el. So I got rid of &environment and instead read `cl-macro-environment' directly if it is bound.

It's quite possible that this solution is not quite right or that something even simpler works; I don't understand these mechanisms in detail.

Looking at it again, I wonder if the following statement in one of ERT's comments is correct:

  ;; If `cl-macroexpand' isn't bound, the code that we're
  ;; compiling doesn't depend on cl and thus doesn't need an
  ;; environment arg for `macroexpand'.

Is it true that we don't need an environment arg? Or do we have to get the byte-compiler's environment and pass it in?


reply via email to

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