From xemacs-m  Sun Feb 16 10:29:14 1997
Received: from martigny.ai.mit.edu (martigny.ai.mit.edu [18.43.0.152])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id KAA24936
	for <xemacs-beta@xemacs.org>; Sun, 16 Feb 1997 10:29:13 -0600 (CST)
Received: from berne.ai.mit.edu by martigny.ai.mit.edu with SMTP
	(1.40.112.8/16.2) id AA216030537; Sun, 16 Feb 1997 11:28:57 -0500
From: Bill Dubuque <wgd@martigny.ai.mit.edu>
Message-Id: <199702161628.AA216030537@martigny.ai.mit.edu>
Received: by berne.ai.mit.edu
	(1.40.112.8/16.2) id AA141350532; Sun, 16 Feb 1997 11:28:52 -0500
Date: Sun, 16 Feb 1997 11:28:52 -0500
To: weiner@infodock.com
Cc: rms@gnu.ai.mit.edu, kwzh@gnu.ai.mit.edu, xemacs-beta@xemacs.org
Subject: Re: eval-last-sexp, {C-x C-e}, now can evaluate interactive forms.

: Date: Sun, 16 Feb 1997 01:15:16 -0800
: From: Bob Weiner <weiner@infodock.com>
: 
: It occurred to me today that it is a bit silly that when eval-last-sexp
: is applied to an (interactive ...) form, the form simply returns nil.
: A more useful outcome would be to have it evaluate as it would when
: the function is called interactively.  I simply extended eval-last-sexp ...

No doubt this is a 'useful' extension, for the reasons suggested by
Bob.  However, I think it would be very poor language design to
introduce this change into just eval-last-sexp. Why?  Because
eval-last-sexp should really be simply EVAL the last s-exp (esp.
if the user is using eval-last-sexp to empirically determine how
the evaluator evaluates an s-exp). If you change its semantics to
'EVAL the last s-exp, EXCEPT if ...' then the user is burdened with
remembering all of the exceptional cases for each different type of
evaluator: eval, eval-last-sexp, eval-region, ...  This might not
seem like much of a burden for a single exception, but when you
pepper the language with many such exceptions the complexity grows
exponentially, e.g. two interacting functions like the above have
four possible cases, three have eight, four have sixteen, etc. This
is precisely the type of complexity that one strives to avoid when
designing a good programming language.

Thus if the change is made, it should be made uniformly throughout
the language, which means both the evaluator and interpreter should
be extended with the same semantics. But viewed in this more general
light it is not clear that this is a good idea since EVAL really 
must ignore '(interactive ...)'. This issue is analogous to the
debate about whether interactive evaluation of DEFVAR's should
special-case single toplevel forms containing a DEFVAR and really
force a rebinding, i.e. whether an analogous 'useful' exception 
should be introduced into interactive evaluation routines.

Ultimately such problems highlight flaws in the original language 
design, and it is probably unwise to propagate such further, thereby
further increasing the complexity of correctly comprehending the 
semantics of the language.

-Bill Dubuque

