[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[no subject]
- To: ALAN at MIT-MC
- From: Kent M. Pitman <KMP at MIT-MC>
- Date: Mon, 9 Jun 80 05:30:00 GMT
- Cc: BUG-LISP at MIT-MC
- Original-date: 9 June 1980 01:30-EDT
Date: 8 June 1980 04:08-EDT
From: Alan Bawden <ALAN at MIT-MC>
To: BUG-LISP
EVAL-WHEN doesn't appear to be a PROGN... it would be nice if EVAL-WHEN
returned the value of the last thing evaled (or NIL?).
This would seem to be more flavorfull anyway.
(BTW the definition of DEFVAR clearly indicates that whoever wrote
it thought that is what EVAL-WHEN did.)
-----
EVAL-WHEN is truly a special form. It has a functional definition
only in the interpreter (ie, only (EVAL-WHEN (... EVAL ...) ...) ever
really gets eval'd on its on merit). The COMPLR and FASLOAD, as near as
I can tell empirically with TRACE, never call EVAL-WHEN -- I presume they
do (AND (EQ (CAR form) 'EVAL-WHEN) (MEMQ interesting-state (CADR FORM)) ...)
type things. Hence, EVAL-WHEN is *NOT* meaningful (read: `legal') except
as a toplevel form. Hence, its return value should be of as little
consequence as possible to discourage relying on it ... The only use for
having it return T/NIL might be in tracing of EVAL-WHEN's consed up by
macros, but that seems pretty marginal to me. I think I would advocate
it always returning NIL. In any case, I believe this all to be site-dependent
as I am pretty sure I didn't tell Bernie about T/NIL return-values when he
was doing the Multics-flavored version of this a month or two ago.
For further `support' of this feeling, note that the compiler will not allow
it in function definitions.
-kmp