[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
eval-case
From: |
Ludovic Courtès |
Subject: |
eval-case |
Date: |
Wed, 21 Oct 2009 13:59:20 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) |
Hello!
Andy Wingo <address@hidden> writes:
> The problem is that eval-case has really murky semantics -- to me at
> least. We've *never* needed to use it in the past, to my knowledge,
> except to distinguish toplevel expressions from lexically nested
> expressions -- an iffy use, IMO. (Any definition should be valid
> anywhere a definition is valid.)
Right, it was essentially useless, but supposedly it was added with
Guile-VM in mind---how visionary! :-)
My suggestion to not deprecate it in 2.0 was motivated by 1.8/2.0
portability. ‘eval-case’ in 1.8 only understands the ‘load-toplevel’
clause. In 2.0, we could add a ‘compile’ clause. That clause is never
true in 1.8, but in 2.0 it could amount to ‘(eval-when (compile) ...)’.
This is so that people could place things like ‘current-reader’ effects
on the right phase:
(eval-case
((compile) (display "current-reader effects for 2.0\n"))
(else (display "current-reader effects for 1.8\n")))
(Actually this isn’t perfect because the ‘else’ branch would also been
taken in 2.0 at load-time.)
OTOH, with ‘(cond-expand (guile-2 ...))’, one can achieve this and more,
which may be a good reason to not worry about it.
Thanks,
Ludo’.
Re: Reporting possibly unbound variables, Andy Wingo, 2009/10/19