[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Confusing problems with (ice-9 syncase) and sc-expand3.
From: |
Marius Vollmer |
Subject: |
Re: Confusing problems with (ice-9 syncase) and sc-expand3. |
Date: |
03 Jun 2001 01:05:44 +0200 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.102 |
Rob Browning <address@hidden> writes:
> Marius Vollmer <address@hidden> writes:
>
> > I think we could extend the semantics of the module system so that it
> > binds symbols not only to variables, but also to other things, like
> > syntax transformers. This is different from storing special #<macro>
> > objects in variables, and would be the right thing IMO.
>
> Hmm. That sounds good, but what effect would it have on redefinitions
> (not that I really know what happens now :>).
Well, if you change a variable binding into a syntax binding, you'll
probably get an error the next time you try to access the binding as a
variable. If you do it the other way around, the macro vanishes, but
the existing expansions wont be undone. (That's how I would do it.
We might aim for more consistency and also try to re-expand macros
when they change, but in my feeling, this likely wont work well in
practice.)
> > This works now, but it does not work when you don't re-export
> > syncase. This is kind of right, since `eval-when' is defined in
> > (ice-9 syncase), and you don't see it unless you use that module.
> > Thus, it shouldn't be recognized as a special form either.
>
> That's expected, though, right? Isn't that just another side effect
> of the fact that ATM you can't export macros that might expand into
> other things that aren't also exported?
Hmm, no. You are using eval-when directly, not in a macro expansion.
> I think for now, I'll probably just fix up cond-expand as I proposed,
Are you referring to this?
| If we just restrict cond-expand to the top level for now and have
| "compile-toplevel" and "load-toplevel" cases, I think we'd probably be
| set for the short term. Perhaps I'll just do that, but we'll also
| have to document that eval-when *does* *not* *work*.
I'm starting to have reservations about using cond-expand for
eval-when work. It clearly says "expand" in the name while eval-when
does more. It can also cause code to be executed right away during
compilation, which does not fit with the original specification of
cond-expand. On the other hand, I like the expressiveness of
cond-expand better, with it's compound expressions and the else
clause. Hmmm.