[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Not clearly non-controversial
- To: brown@DEC-HUDSON.ARPA, COMMON-LISP@SU-AI.ARPA
- Subject: Not clearly non-controversial
- From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
- Date: Thu, 14 Feb 85 14:41 EST
- In-reply-to: The message of 6 Feb 85 12:52-EST from brown at DEC-HUDSON
Date: Wed, 06 Feb 85 12:52:15 EST
Re: Clearly non-controversial
A string is returned that identifies the current user of the
Common Lisp system. If a reasonable name cannot be determined,
NIL is returned (or an empty-string?).
(It has been suggested that this should be called something like
USER-INFORMATION and take a lot of keyword arguments.)
Not just user information, but system information. eg, on the LispM it
means little (even in Common Lisp) to know the guy's name is "Joe" unless
you know what machine or site that name is relative to. At the least,
you'd need a way of getting the machine name, too. The USER-INFORMATION
thing sounds a little more plausible, but I'd prefer to see a specific
suggestion before saying go ahead.
DELETE-SETF-METHOD access-fn [function]
Removes the update form associated with the symbol access-fn.
The access function can no longer be used as generalized
I dislike the use of the morpheme "DELETE-" in this context. The Lisp
Machine uses "UN" tacked onto the defining form name, which is easy
to remember and doesn't feel like it wants a second argument of a list
to delete the thing from. Perhaps we should have a lot of UNthings.
Perhaps we should have a special form UNDO which works like SETF
but undoes things. eg, (UNDO (DEFINE-SETF-METHOD ...)) would undo a
SETF method. (UNDO (DEFUN FOO (X) ...)) would undo a DEFUN. We'd have
to define clearly the effect of:
(DEFUN F (X) X) (DEFUN F (X) (1+ X)) (UNDO (DEFUN F (X) (1+ X)))
If it wasn't to make F be an identity function again, then UNDO might
be a slightly misleading name. Anyway, I'd rather address this general
problem than add a ton of special case DELETE-mumble or UNmumble
COMPILEDP symbol [function]
Returns NIL if the symbol does not have a compiled function
definition. Returns T if the symbol has a compiled function
definition which was not compiled by the COMPILE function;
for example, loaded from a compiled file. Returns the
interpreted function definition if the function was compiled
by the COMPILE function.
(DEFUN FOO (X) X)
(DEFUN F ()
(FLET ((FOO (Y) (1+ Y)))
I would feel better if any COMPILEDP thing took an argument of
an object and told you if it were compiled. So you could write
(COMPILEDP #'symbol) instead.
Personally, I wish COMPILE had been defined to just return its result
rather than to also install it because it propagates the same kind of
confusion. But I guess it's a little late to worry about that now.