[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: FUNCTION-TYPE (Version 5)
- To: CL-Cleanup@SAIL.STANFORD.EDU
- Subject: Re: Issue: FUNCTION-TYPE (Version 5)
- From: NGALL@G.BBN.COM
- Date: 23 Jun 1987 01:34-EDT
- Cc: Masinter.pa@XEROX.COM
- In-reply-to: <870616-155121-101@Xerox>
- Sender: NGALL@G.BBN.COM
Date: 16 Jun 87 15:33 PDT
From: Masinter.pa@Xerox.COM
FUNCTION-TYPE is one of the more difficult issues facing the cleanup
committee. This is a tough but important issue that involves some
fundamental trade-offs, so discussion by the whole X3J13 committee is
called for.
My main concern about losing symbols as valid function objects (i.e.,
things that can be given to apply and funcall) is that it will make
the "functional style" of Lisp more difficult to debug.
For example, I use the following reader macro to allow function names
(symbols) to be used as arguments when my code is in the debugging
phase and "true" fucntions to be used when my code is "finished".
(defun |#!-reader| (stream subchar arg)
(declare (ignore subchar arg))
(let ((fname (read stream t nil t)))
(if *debugging-p*
`',fname
`#',fname)))
(set-dispatch-macro-character
#\#
#\!
(if *debugging-p* '|#!-reader| #'|#!-reader|))
Then, I can code the following (in most implementations):
(proclaim '(optimze (speed 0) (safety 3)))
(proclaim '(notinline froz))
(eval-when (compile load eval) (defparameter *debugging-p* t))
(defun froz ...)
...(funcall #!froz ...)...
...(mapcar #!froz ...)...
(defparameter *action-seq* `(,#!froz ,#!zorf ,#!(lambda ...) ...))
...
(apply (elt *action-seq* i) ...)
I can at any time trace froz in order to find out what is going on
(besides tracing I may also do some types of profiling). (Cf. trace,
pg 441.) And what is probably even more important, when my
observation of the behavior of froz leads me to redefine froz, every
piece of code or data-structure that references the function name froz
will correctly get the new definition.
As CLtL is currently vague as to when it is permissable to dereference
a function name to its definition (compile-time, load-time, or
apply-time), I have to avoid implementations that do not deference at
apply-time.
Under the strict redefinition proposal, I would have to recompile
every data structure that contained #'froz. In other words, it would
make functional objects impratical to debug.
Under both proposals. function names (i.e., symbols and
lambda-expressions) are (virtually) eliminated as functional objects.
This is great way to "purify" the semantics of the language, but it
puts a big burden on implementors to come up with development environments
that have the ease of debugging that function names provided.
I think I have probably mixed up a few issues here (it is late for
me), but I wanted to put in my warning that flushing function names
that can be passed around as functions has some major consequences on
Lisp style due to debugging/redefinition issues.
-- Nick