From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Nala Ginrut Newsgroups: gmane.lisp.guile.devel Subject: Re: [PATCH] Add-native-hashtable-helper-functions Date: Wed, 27 Mar 2013 14:32:38 +0800 Organization: HFG Message-ID: <1364365958.2730.19.camel@Renee-desktop.suse> 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: 8bit X-Trace: ger.gmane.org 1364365978 24010 80.91.229.3 (27 Mar 2013 06:32:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 27 Mar 2013 06:32:58 +0000 (UTC) Cc: Ludovic =?ISO-8859-1?Q?Court=E8s?= , guile-devel To: Daniel Hartwig Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Mar 27 07:33:23 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 1UKjv9-0001V4-Qv for guile-devel@m.gmane.org; Wed, 27 Mar 2013 07:33:16 +0100 Original-Received: from localhost ([::1]:47028 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKjul-0005pP-Sm for guile-devel@m.gmane.org; Wed, 27 Mar 2013 02:32:51 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:47393) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKjuh-0005p8-7a for guile-devel@gnu.org; Wed, 27 Mar 2013 02:32:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UKjue-0005do-Qn for guile-devel@gnu.org; Wed, 27 Mar 2013 02:32:47 -0400 Original-Received: from mail-da0-x236.google.com ([2607:f8b0:400e:c00::236]:65089) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKjud-0005dA-0E; Wed, 27 Mar 2013 02:32:43 -0400 Original-Received: by mail-da0-f54.google.com with SMTP id p1so3978903dad.13 for ; Tue, 26 Mar 2013 23:32:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:subject:from:to:cc:date:in-reply-to :references:organization:content-type:x-mailer:mime-version :content-transfer-encoding; bh=SeMxh+oZqhw4GDx5GYZ82mwELYGKrAwDT+yyl2wd7jk=; b=SLoRA6z2kjX4/lkG90xQZ86ZDaiKw2jmxC+/r8aEzR+b4ocqhVeVQeQoe08I3Fh9E4 q7zatkWTfDfwiuhKLOUxRV7r20ngW4W7F/TdFj+vQS7So7DBb1dww+5tjeyMIFantMps LfQv9jNSCTqAW86e2LACK0JoP7Pl8KV1UI9NTyRDe/C8DNDFJ+aLWLE2cGJl8j601bci bEuPJsLY0sM3g5TIxntxGAIlnsMwnUBBtumEp0bRCfTFmHs8uwXZ71sfjuQJ4St1tqRb l8PEjw2X+bECdnxU6xkBAjkL4rYl5GAHux0nYjm8X2eQxZdaPOPAfVakEsqtSdo37nLp Ykbg== X-Received: by 10.68.211.8 with SMTP id my8mr27470060pbc.7.1364365961935; Tue, 26 Mar 2013 23:32:41 -0700 (PDT) Original-Received: from [147.2.147.112] ([61.14.130.226]) by mx.google.com with ESMTPS id 1sm20318465pba.32.2013.03.26.23.32.39 (version=SSLv3 cipher=RC4-SHA bits=128/128); Tue, 26 Mar 2013 23:32:41 -0700 (PDT) In-Reply-To: X-Mailer: Evolution 3.4.4 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400e:c00::236 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:16015 Archived-At: On Wed, 2013-03-27 at 13:10 +0800, Daniel Hartwig wrote: > On 27 March 2013 08:47, Nala Ginrut wrote: > > > > 在 2013-3-27 AM5:59，"Ludovic Courtès" 写道： > > > > > >> > >> Nala Ginrut skribis: > >> > > Hi now > > >> > * hash-items: get the amount of items in the hash table > >> > >> There’s already ‘hash-count’, 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. > Well, could you point me out how can I get the amount of items with hash-count in constant time? IMO, return the count of inner record is most explicit way. > The two fundamental queries on dictionary types are: extract the value > associated with a given key; and iterate over all key–value 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.) > Yes I won't against assoc & iterate are the most common operations. But as an user who writing programs with Guile, people can't just use the most common operations. They need more helpful things to alleviate the workload. Though we can write all things with most common operations, that's terrible for a practical programming. That just like to say, I gave you all the bricks and cement, build whatever you want, but don't ask for anything extra can be built with bricks and cement. And even our aim is to provide a clean and elegant language implementation, but if it's too clean and elegant, it's only for appreciation, not using. I'm not forcing to add my hash-items or hash-size, but I have to call for any implementation for these two things, and I wish they add into the core. I have to send this patch since I can't find any outer way to get the amount of items in constant time but export it from the inner struct. > >> > +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_VECTOR > >> > (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’t seem sufficiently common to warrant a new procedure. WDYT? > >> > > > > I add it because I do need it when I wrote artanis, but Racket provides it. > > 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—adding a > few such procedures here and there to suite every tiny itch—the result > 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’. > >> > >>