From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Mikael Djurfeldt Newsgroups: gmane.lisp.guile.devel,gmane.lisp.guile.user Subject: Re: About hash-table iterators Date: Tue, 27 Jan 2004 11:07:53 -0500 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: References: <1074950358.23546.902.camel@localhost> Reply-To: djurfeldt@nada.kth.se NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1075220062 6577 80.91.224.253 (27 Jan 2004 16:14:22 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 27 Jan 2004 16:14:22 +0000 (UTC) Cc: guile-user@gnu.org, djurfeldt@nada.kth.se, m.vollmer@ping.de, guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Jan 27 17:14:06 2004 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AlVqn-0000Sk-00 for ; Tue, 27 Jan 2004 17:14:05 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AlVos-0001cG-Sy for guile-devel@m.gmane.org; Tue, 27 Jan 2004 11:12:06 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AlVlz-0000nh-Dz for guile-devel@gnu.org; Tue, 27 Jan 2004 11:09:07 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AlVlQ-0000gM-Os for guile-devel@gnu.org; Tue, 27 Jan 2004 11:09:04 -0500 Original-Received: from [213.212.20.77] (helo=kvast.blakulla.net) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AlVkp-0000X8-2v; Tue, 27 Jan 2004 11:07:55 -0500 Original-Received: from chunk.mit.edu ([18.42.2.92] helo=chunk ident=Debian-exim) by kvast.blakulla.net with esmtp (Exim 3.36 #1 (Debian)) id 1AlVko-0001TG-00; Tue, 27 Jan 2004 17:07:54 +0100 Original-Received: from mdj by chunk with local (Exim 4.30) id 1AlVkn-0006th-K8; Tue, 27 Jan 2004 11:07:53 -0500 Original-To: Roland Orre In-Reply-To: <1074950358.23546.902.camel@localhost> (Roland Orre's message of "Sat, 24 Jan 2004 14:19:18 +0100") User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.2 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 Xref: main.gmane.org gmane.lisp.guile.devel:3321 gmane.lisp.guile.user:2730 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:2730 [Cross-posting to guile-devel] Roland Orre writes: > The elements of a hash table I consider the handles, not the key and > the value as separate entities, therefore I don't consider the current > iterators hash-map and hash-for-each in guile 1.7 very useful and the > basic iterators I've used over the year, i.e iterating over the handles, > can not be constructed from them. To be able to implement my previous > functionality I had to copy and modify a few routines from hashtab.c to > be able to implement e.g > > hash-for-each-handle > hash-map-handles > and from the latter can then e.g hash-table->list be implemented > > (define-public (hash-table->list htable) (hash-map-handles id htable)) > > and when you don't want to be able to modify the original table you can > use hash-map instead: > (define-public (hash-table-copy->list htable) (hash-map cons htable)) > > Is this a general interest? In that case these maybe they should be > considered the basic iterators provided instead of hash-for-each and > hash-map as the latter can be implemented from the other but not vice > versa? The design decision for hash-for-each and hash-map was to abstract away the handle's, which are lower-level details of the representation of the table, and, also, to promote a functional style of programming. The decision is supported by the same choice made for Common Lisps's `maphash' (although Common Lisp has setf so that the side-effects (the *only* effects, btw) also include mutating the table). Also, java does not use the concept of handles either. However, we *do* support handles in another set of functions. (Unfortunately, the abstraction is not complete here. If we pass out a handle object, we should have accessor and mutator functions for this object and not just presume that it is a pair!) So, I'm inclined to support your idea of introducing hash-for-each-handle. I don't think we need to introduce hash-map-handles, though. Also: Is it the case that hash-map has a really bad name? It strikes me that one would expect hash-map to return another hash table. Should it instead be named hash-map-to-list or something better? M _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel