Re: eval-when and eval-case issues.

[Rob Browning]

Marius Vollmer <address@hidden> writes:

> Somehow, I like `eval-case' better since it is more expressive.  Maybe
> this added expressiveness doesn't make any sense, since I didn't
> understand eval-when good enough when I introduced eval-case.  I don't
> understand it much better now, only that there is more to it than I
> thought.

You and me both.  IMO the compile vs load vs eval issues are a little
tricky, especially in guile since we have what appear to be two
competing macro systems.

> What's more, `cond-expand' might be of interest as well, as a
> general compile-time feature test device.  Maybe it can absorb the
> eval-when functionality.  That is, when we can get by with
> `cond-expand' being the only feature/situation test thing, I would
> go for it.  `eval-when' and maybe `eval-case' could be defined in
> terms of it, for compatibility.

Well, for at least SRFI-0, cond-expand is restricted to the top level,
and is really described as being intended to indicate the presense or
absence of features.  To me, indicating whether you're compiling,
loading, or evaling (or whatever set of distinctions we select) seems
like an orthogonal thing.  So I tend to think that stuff should be
handed by a separate construct.

I suppose I could see compilation as a "feature", but that's not how I
initially thought about it.

> I'm not sure whether I want the complicatedness of the CL eval-when,

me neither :>

> (but I want at least understand why it is there).  The syncase
> eval-when specification seems quite simple to me after reading the
> CL spec.  This might be an advantage (it's easy to understand) or a
> disadvantage (doesn't really do what is needed, for example when
> eval-whens are nested within themselves, or within non-toplevel
> other forms).  I don't know yet.

Well, with both cond-expand and psyntax's eval-when, non-top-level
invocations are forbidden.  This seems like a wise restriction to
start with, we can always relax it later if it seems necessary and the
behavior can be clearly described.

That said, if I'm understanding eval-when right, I'm not sure I like
the distinctions that it makes.  After reading the source a bit and
trying to match that with the available comments, AFAICT, its "eval"
case (from its situational set: compile load eval) applies to forms
being loaded from a text .scm file or typed at a prompt, but *not*
forms being evaluated from a compiled object file.  Personally, I
would have expected code coming from a .scm file vs code coming from
an "object file" to be indistinguishable.

Right now, though, I'm still blocked on the eval-when weirdness I
posted earlier -- how sc-expand3 only behaves as I'd expect if (ice-9
syncase) has been loaded directly into guile-user, but not if it's
been loaded and used indirectly via another module.

Actually, though after looking around, I didn't realize that eval-when
isn't actually used anywhere in guile's code outside psyntax/syncase,
so unless it's used indirectly somehow in expansions, I suppose we
could just ignore eval-when and enhance/use cond-expand.

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

Thanks

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