[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
A lambda question
- To: Scott.Fahlman@B.GP.CS.CMU.EDU, skona%csilvax@hub.ucsb.edu
- Subject: A lambda question
- From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Mon, 1 Aug 88 10:40 EDT
- Cc: CL-Cleanup@SAIL.Stanford.EDU
- In-reply-to: The message of 26 Jul 88 20:20 EDT from Scott.Fahlman@B.GP.CS.CMU.EDU, The message of 26 Jul 88 16:53 PDT from Skona Brittain <skona%csilvax@hub.ucsb.edu>
Date: Tue, 26 Jul 88 20:20:57 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU
If there were to be such a function, what would be a
good name for it?
How about EXTRACT-LAMBDA-EXPRESSION ?
The T language provides such a primitive. It is called DISCLOSE
(named for symmetry with the ENCLOSE primitive which occurs in some
Scheme dialects and coerces a lambda expression into a procedure).
DISCLOSE may be overly generic-sounding for CL use, but I recommend
DISCLOSE-DEFINITION.
I assume that the proposal will allow this function to return NIL if
the original lambda expression has been compiled or optimized to the
point where it can no longer be retrieved? I wouldn't want to require
memory-tight implementations to keep around the original form in all
cases.
Since some applications for DISCLOSE have semantic impact, I don't agree
that it should be possible for an implementation to simply throw away
the information. I believe that we should spell out particular cases
in which it is or is not permissible. My personal preferences follow:
- No compiler should be required to retain the source code
when using the file compiler. That is, using COMPILE-FILE
does not make the definition available in the environment into
which the definitions are subsequently LOADed.
- I am agnostic about interactive DEFUN, etc. I am content to see
this information retained only at the discretion of the
interpreter.
- I would prefer that arguments to COMPILE be retained, and possibly
defuns done by explicit EVAL as well. The reason for this is that
programs like Macsyma which have need of this function do not just
go around peeking into arbitrary functions (in my experience). They
usually want to peek into functions that they themselves instantiated.
So primitives that allow explicit runtime instantiation of functions
on a case-by-case basis should be reliably invertible (in my opinion).
Notes:
- I would be ammenable to permitting this function to be SETF-able,
so that people could ``NIL out'' definitions they didn't want to
retain.
- I would also be ammenable to having a special argument to COMPILE
saying that the information must be retained. I don't care what
the default value was.
- If there is not any reliable situation in which a definition will
have this information retained, then all the uses I have ever had
for this except for pretty printing are nullified. Perhaps the
pretty printing argument is reason enough to have it, though.
- There is some question about whether in the case of named objects,
(DEFUN FOO (X) X)
(DISCLOSE-DEFINITION #'FOO) => (LAMBDA (X) X) or (DEFUN FOO (X) X)?
I think the latter.
Does whether FOO is still fdefined matter? I think not.