[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Defun inside Let
- To: DCP@SCRC-QUABBIN.ARPA
- Subject: Defun inside Let
- From: Jonathan A Rees <JAR@MC.LCS.MIT.EDU>
- Date: Thu, 30 Jan 86 17:05:05 EST
- Cc: common-lisp@SU-AI.ARPA
- In-reply-to: Msg of Thu 30 Jan 86 16:08 EST from David C. Plummer <DCP at SCRC-QUABBIN.ARPA>
- Sender: JAR0@MC.LCS.MIT.EDU
Date: Thu, 30 Jan 86 16:08 EST
From: David C. Plummer <DCP at SCRC-QUABBIN.ARPA>
... That's all fine and dandy. Now come the hard parts.
Is the system expected to know that >the old version< of
add-and-increment is a lexical closure over some variables and make the
new one share that same environment?
- What if I wanted to add a variable to the lexical environment? What
forms to I type to splice something in?
I don't have answers for any of those. It's not clear to me there ARE
answers to some of them. What if somebody on the ISO board thinks up
roughly the same questions? If somebody does have >answers<, I'd like
to hear them. My personal feeling is that DEFUN that requires a
non-null lexical environment, such as created by LET, is a timebomb
The questions you raise are valid and important ones, but I don't see
what they have to do with DEFUN. They apply equally to SETQ, SETF,
FLET, LABELS, etc., and are bound to arise the minute you have lexical
closures at all. Yes, it would be nice to be able to update the code
for a closure, alter environments, and so forth, for debugging. But I
don't see why debugging questions should enter into this semantic
question. Is there some reason that DEFUN is different? If there's a
problem with making (DEFUN FOO ...) mean the same [except with respect
to debugging, which Common Lisp doesn't address anyhow] as (SETF
(SYMBOL-FUNCTION 'FOO) #'(LAMBDA ...)), why isn't that problem also a
problem with the SETF form?