From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Hartwig Newsgroups: gmane.lisp.guile.devel Subject: Re: [PATCH] Add-native-hashtable-helper-functions Date: Wed, 27 Mar 2013 13:10:58 +0800 Message-ID: References: <1364294433.2730.2.camel@Renee-desktop.suse> <874nfxvn4u.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1364361073 18741 80.91.229.3 (27 Mar 2013 05:11:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 27 Mar 2013 05:11:13 +0000 (UTC) Cc: =?UTF-8?Q?Ludovic_Court=C3=A8s?= , guile-devel To: Nala Ginrut Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Mar 27 06:11:40 2013 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UKie5-0003eW-Ka for guile-devel@m.gmane.org; Wed, 27 Mar 2013 06:11:33 +0100 Original-Received: from localhost ([::1]:38871 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKidh-0003G9-IG for guile-devel@m.gmane.org; Wed, 27 Mar 2013 01:11:09 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:34567) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKidd-0003G3-J9 for guile-devel@gnu.org; Wed, 27 Mar 2013 01:11:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UKidX-0007rS-MF for guile-devel@gnu.org; Wed, 27 Mar 2013 01:11:05 -0400 Original-Received: from mail-ia0-x22a.google.com ([2607:f8b0:4001:c02::22a]:57634) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKidX-0007rH-IM; Wed, 27 Mar 2013 01:10:59 -0400 Original-Received: by mail-ia0-f170.google.com with SMTP id h8so7129747iaa.15 for ; Tue, 26 Mar 2013 22:10:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=igY8QbTBS/EF4WABdynQVaQePxQaY/dt9jDAuf6qVCM=; b=j8mk3xRWVK4D+7mKvdsjq6m65Enfj6z8IZ3/LeuQZoHn9J11phax3esQ2ZaoP/xfTo fenuCB0zJWtkUGWivO+gyyJzJKpwdMPaU2Gx77A3chQXDHa6WuGONlx4pNy0oaGoRMQz K3SB0jJ9NnU+q6m9PgJdP9rlguScd3jpPZpa21iaycYCRpvFDO9L93bb2RdIdtc0PTUT Yhd8IA0xvbzFjGhpDROWq0kJL1d3xUDm308eiIenJ9SKjfBgF1IiD3/6PbXha6RYLV5O 10KwQA6d8DFyqZe6vu1W0gfVX+yGWD0EedKL1eY8IgzioZtmndYbtXbPFaldZ72MhB+l riJw== X-Received: by 10.50.134.4 with SMTP id pg4mr3365085igb.96.1364361058891; Tue, 26 Mar 2013 22:10:58 -0700 (PDT) Original-Received: by 10.64.26.168 with HTTP; Tue, 26 Mar 2013 22:10:58 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4001:c02::22a X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:16014 Archived-At: On 27 March 2013 08:47, Nala Ginrut wrote: > > =E5=9C=A8 2013-3-27 AM5:59=EF=BC=8C"Ludovic Court=C3=A8s" = =E5=86=99=E9=81=93=EF=BC=9A > > >> >> Nala Ginrut skribis: >> Hi now >> > * hash-items: get the amount of items in the hash table >> >> There=E2=80=99s already =E2=80=98hash-count=E2=80=99, recently added. >> > > If I need to check the amount of items > each time in the loop, hash-count will do redundant visit for all items. = But > hash-items is efficient. > If you refer back to the thread discussing this, a constant time count of items was rejected in favour of the more general operator, and even that is provided only as a convenience. That a constant time count of items is available is an implementation detail. It is generally undesirably to expose such details. The two fundamental queries on dictionary types are: extract the value associated with a given key; and iterate over all key=E2=80=93value pairs. Algorithms where hash-count is a critical operation (e.g. run inside a loop) are poorly designed, and not something to be encouraged by providing constant-time guarantees on that in the API. A well-designed API encourages sound algorithm design by the interfaces it _omits_ just as much those it includes. Here the goal is to expose an interface to the abstract data type, not any particular implementation. (Yes, some details are naturally leaked e.g. alist structure, but this is not a justification to leak even more.) >> > +SCM_DEFINE (scm_hash_size, "hash-size", 1, 0, 0, >> > + (SCM table), >> > + "Get the size of this hash table.") >> > +#define FUNC_NAME s_scm_hash_size >> > +{ >> > + SCM_VALIDATE_HASHTABLE (1, table); >> > + return scm_from_uint (SCM_SIMPLE_VECTOR_LENGTH (SCM_HASHTABLE_VECTO= R >> > (table))); >> >> That returns the number of buckets, which is an internal detail, and >> probably not a useful one. >> > > Yes, maybe, but I think we'd better provide it since we can see the size = in > the REPL, people may want to get this info in program for some statistic. If you find this inconsistent, the information can be removed from the REPL= . >> > +(define (hash-keys table) >> > + "Return all the keys from hash table." >> > + (hash-map->list (lambda (x y) x) table)) >> >> That doesn=E2=80=99t seem sufficiently common to warrant a new procedure= . WDYT? >> > > I add it because I do need it when I wrote artanis, but Racket provides i= t. > So I think it's useful. It is peculiar to _need_ only the keys of a dictionary, even if only at some point of the program. This justification immediately suggests that something may be lacking in the program design. Again, it is not something that should be encouraged by exposing in the API, especially as it is trivial to implement in the rare cases where it is needed. Much of the grace and power of Scheme comes from its simple, mathematical design. The proposed procedures are only useful in specific, obscure situations. One may proceed down this path=E2=80=94addin= g a few such procedures here and there to suite every tiny itch=E2=80=94the res= ult is hundreds or more of these little procedures that add very little value _to the language_, while making it more difficult to learn (by exposing unnecessary nuances), increasing the maintenance burden, and limiting the freedom to explore other implementation options in the future. Regards > >> Thanks, >> Ludo=E2=80=99. >> >>