>>>> "M" == Michael Sperber
M> "Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
> I don't see a real use case for the return value of Fclrhash,
> find it hard to imagine one. I think it's preferable to *not*
> document the return value of functions that are only useful for their
> side effects. Mike?
Perhaps the Common Lisp spec should have specified the return value
of clrhash to be NIL.
In the absence of a useful value to return, there is indeed a school
of thought that says to return the "current object". One can see this
also in the Java API in things like StringBuilder, where it is more
But whether or not you think it's a good idea, it's what the Common
Lisp committee chose, and it's what we've done for at least the past
10 years, so DON'T CHANGE IT NOW. I think it should be documented.
It was a failure of omission on my part to not document it 10 years ago.
Syntactically, chaining the current object through the return value
works better in Java than in Lisp. E.g. the following is fairly readable.
StringBuilder b = new StringBuilder()
M> This case is in the tradition of "linear-update" functions, so I think
M> the return value is OK. I can thread manipulations of the hash table
M> through nested function calls like
M> (clrhash (clrhash (puthash ...)))
> Is it obvious that returning VALUE is the right thing? What
> Common Lisp Do?
M> Common Lisp would return t if the hash entry was found, nil if not.
M> While theoretically more useful, I don't think I've ever seen a case
M> where I would have used the return value.
M> Cheers =8-} Mike
M> Friede, Völkerverständigung und überhaupt blabla
M> XEmacs-Patches mailing list
XEmacs-Patches mailing list