9:13 p.m.
changeset: 4410:aae1994dfeec98b2f207acb6e9682209b7f0c67b
tag: tip
user: Aidan Kehoe <kehoea(a)parhasard.net>
date: Mon Jan 21 22:12:36 2008 +0100
files: src/ChangeLog src/elhash.c
description:
Document return values for #'puthash, #'clrhash.
2008-01-21 Aidan Kehoe <kehoea(a)parhasard.net>
* elhash.c (Fputhash): Document the return value.
(Fclrhash): Ditto.
diff -r 3ff01259c4a26143b328b31da55afa0914836cf5 -r
aae1994dfeec98b2f207acb6e9682209b7f0c67b src/ChangeLog
--- a/src/ChangeLog Mon Jan 21 16:26:36 2008 +0100
+++ b/src/ChangeLog Mon Jan 21 22:12:36 2008 +0100
＠＠ -1,3 +1,8 ＠＠ 2007-12-26 Aidan Kehoe <kehoea＠parhasa
+2008-01-21 Aidan Kehoe <kehoea(a)parhasard.net>
+
+ * elhash.c (Fputhash): Document the return value.
+ (Fclrhash): Ditto.
+
2007-12-26 Aidan Kehoe <kehoea(a)parhasard.net>
* casetab.c:
diff -r 3ff01259c4a26143b328b31da55afa0914836cf5 -r
aae1994dfeec98b2f207acb6e9682209b7f0c67b src/elhash.c
--- a/src/elhash.c Mon Jan 21 16:26:36 2008 +0100
+++ b/src/elhash.c Mon Jan 21 22:12:36 2008 +0100
＠＠ -1158,7 +1158,7 ＠＠ If there is no corresponding value, retu
}
DEFUN ("puthash", Fputhash, 3, 3, 0, /*
-Hash KEY to VALUE in HASH-TABLE.
+Hash KEY to VALUE in HASH-TABLE, and return VALUE.
*/
(key, value, hash_table))
{
＠＠ -1222,6 +1222,7 ＠＠ Return non-nil if an entry was removed.
DEFUN ("clrhash", Fclrhash, 1, 1, 0, /*
Remove all entries from HASH-TABLE, leaving it empty.
+Return HASH-TABLE.
*/
(hash_table))
{
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches
1:11 a.m.
QUERY
I don't see a real use case for the return value of Fclrhash, and I
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?
In the case of puthash, there's an obvious theoretical use, in fact
two of them:
(setq would-this-want-key-or-value?
(puthash (complex-expr-1) (complex-expr-2) hash-table))
Is it obvious that returning VALUE is the right thing? What Would
Common Lisp Do?
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches
9:27 a.m.
Ar an cúigiú lá is fiche de mí Eanair, scríobh Stephen J. Turnbull:
QUERY
I don't see a real use case for the return value of Fclrhash, and I
find it hard to imagine one.
http://www.lispworks.com/documentation/HyperSpec/Body/f_clrhas.htm#clrhash
It’s available in Common Lisp. I don’t see any win to being incompatible
with Common Lisp in this, and if we’re going to be compatible, we may as
well document it.
Ugh, though, GNU always return nil. Maybe I can submit a bug report to them.
I think it's preferable to *not* document the return value of
functions
that are only useful for their side effects. Mike?
In the case of puthash, there's an obvious theoretical use, in fact
two of them:
(setq would-this-want-key-or-value?
(puthash (complex-expr-1) (complex-expr-2) hash-table))
Is it obvious that returning VALUE is the right thing? What Would
Common Lisp Do?
It would use #'setf instead--that’s what the hyperspec describes, and the
implementation at telnet prompt.franz.com tells me that puthash isn’t bound.
GNU return VALUE, but don’t document it.
--
¿Dónde estará ahora mi sobrino Yoghurtu Nghé, que tuvo que huir
precipitadamente de la aldea por culpa de la escasez de rinocerontes?
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches
2:35 p.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
I don't see a real use case for the return value of Fclrhash, and
I
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?
This case is in the tradition of "linear-update" functions, so I think
the return value is OK. I can thread manipulations of the hash table
through nested function calls like
(clrhash (clrhash (puthash ...)))
Is it obvious that returning VALUE is the right thing? What Would
Common Lisp Do?
Common Lisp would return t if the hash entry was found, nil if not.
While theoretically more useful, I don't think I've ever seen a case
where I would have used the return value.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches
9:07 p.m.
>>>> "M" == Michael Sperber
<sperber(a)deinprogramm.de> writes:
M> "Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
> I don't see a real use case for the return value of Fclrhash,
and I
> 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
obviously useful.
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()
.append(foo)
.append(bar)
.append(baz);
Martin
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
Would
> 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> --
M> Cheers =8-} Mike
M> Friede, Völkerverständigung und überhaupt blabla
M> _______________________________________________
M> XEmacs-Patches mailing list
M> XEmacs-Patches(a)xemacs.org
M> http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches
5932
days inactive
5937
days old
4 comments
5 participants
participants (5)
-
Aidan Kehoe -
Aidan Kehoe -
Martin Buchholz -
Michael Sperber -
Stephen J. Turnbull