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

[Rob Browning]

Marius Vollmer <address@hidden> writes:

> 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.)

Yes, and there are a lot of other things I'd rather have fixed up in
guile first :>

> 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*.

More or less (see below).  I'm just hacking around now, and learning
the stuff that'll be required no matter what we decide on for our
"final approach".

> I'm starting to have reservations about using cond-expand for
> eval-when work.

I've been sloppy with my names here.  I meant boot-9's eval-case when
I said cond-expand above.  I think I mentioned in another message that
given the name, and the verbage in the SRFI, cond-expand doesn't seem
quite right for this purpose.

I'm actually planning to see about enhacing *eval-case* to support
compile-toplevel.

Sorry for the confusion.

-- 
Rob Browning <address@hidden> PGP=E80E0D04F521A094 532B97F5D64E3930