Re: Confusing problems with (ice-9 syncase) and sc-expand3.

[Marius Vollmer]

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.