[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: LET-TOP-LEVEL (version 1)
- To: pierson@mist
- Subject: Issue: LET-TOP-LEVEL (version 1)
- From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
- Date: Wed, 2 Mar 88 15:41:45 PST
- Cc: cl-cleanup@sail.Stanford.EDU
- In-reply-to: Dan L. Pierson's message of Wed, 02 Mar 88 08:54:41 EST <8803021354.AA22763@mist.UUCP>
re: [re-grinding]
Good. I do it too. The only reason I mention it here is to ask anyone
else who cares about it to raise their objections now, or forever ...
re: ... so that anything said about "anonymous lambdas" should also be
equally applicable to "defun"'s.
The relevant sentence is on page 67: "Other implementation-dependent
bookkeeping actions may be taken as well by DEFUN."
I don't believe that the sentence about "Other implementation-dependent ..."
negates the understanding of DEFUN as basically a rewrite to
(setf (symbol-function 'foo) #'(lambda (x y ...) ...))
If anything needs "clarifying" around this topic, perhaps it should be
just that. In particular, the sorts of things I imagine would legitimately
fall into "Other implementation-dependent ..." are items like hooks for
cross-referencing programs, file-indexing programs, extensions the
normal error-signalling upon redefinition (to facilitate "patch" files etc).
But nothing that would change the underlying equation of DEFUN's with
named lambda functions.
[Now, the corresponding issue re DEFMACRO isn't so nice. I hope some
excuse can be found to do the simple thing with it too, rather than
requiring some singular behaviour with regard to capturing lexical
environments. But this is another issue, another can of worms.]
-- JonL --
P.S. Apparently the return address in your messages isn't good enough
to be used through Labrea.Stanford.edu; do you have another?