Re: moving more cl seq/mapping support into core

[Christian Ohler]

 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?

Christian.