* About hash-table iterators @ 2004-01-24 13:19 Roland Orre 2004-01-27 16:07 ` Mikael Djurfeldt 0 siblings, 1 reply; 4+ messages in thread From: Roland Orre @ 2004-01-24 13:19 UTC (permalink / raw) 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? Best regards Roland _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: About hash-table iterators 2004-01-24 13:19 About hash-table iterators Roland Orre @ 2004-01-27 16:07 ` Mikael Djurfeldt 2004-01-27 17:39 ` Roland Orre 2004-02-13 23:22 ` Mikael Djurfeldt 0 siblings, 2 replies; 4+ messages in thread From: Mikael Djurfeldt @ 2004-01-27 16:07 UTC (permalink / raw) Cc: guile-user, djurfeldt, m.vollmer, guile-devel [Cross-posting to guile-devel] Roland Orre <orre@nada.kth.se> 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: About hash-table iterators 2004-01-27 16:07 ` Mikael Djurfeldt @ 2004-01-27 17:39 ` Roland Orre 2004-02-13 23:22 ` Mikael Djurfeldt 1 sibling, 0 replies; 4+ messages in thread From: Roland Orre @ 2004-01-27 17:39 UTC (permalink / raw) Cc: guile-user, m.vollmer, guile-devel On Tue, 2004-01-27 at 17:07, Mikael Djurfeldt wrote: > [Cross-posting to guile-devel] > > Roland Orre <orre@nada.kth.se> 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 <snip> > 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. Yes, this is a good argument, although I like functional programming style I'm far away from any purist here. Often I like the imperative style of doing things because it's often more intuitive (at least for me...). Although in the case with hash tables I consider the handle keeping the value together as fundamental and is often using it this way. > 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!) Yes you are right. This may save a lot of work in the long run... > So, I'm inclined to support your idea of introducing > hash-for-each-handle. I'm very pleased by this (the less code to maintain in user space, the better) > I don't think we need to introduce hash-map-handles, though. No, you are right, that is not necessary. Best regards Roland _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: About hash-table iterators 2004-01-27 16:07 ` Mikael Djurfeldt 2004-01-27 17:39 ` Roland Orre @ 2004-02-13 23:22 ` Mikael Djurfeldt 1 sibling, 0 replies; 4+ messages in thread From: Mikael Djurfeldt @ 2004-02-13 23:22 UTC (permalink / raw) Cc: m.vollmer, djurfeldt Mikael Djurfeldt <mdj@mit.edu> writes: > 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. BTW, since then I've looked around, and virtually every Scheme implementation I find have made the same choice as we have. > 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. Since I didn't get any feedback I went ahead and checked this into CVS HEAD: 2004-02-13 Mikael Djurfeldt <djurfeldt@nada.kth.se> (scm_internal_hash_for_each_handle, scm_hash_for_each_handle): New functions. > 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? 2004-02-13 Mikael Djurfeldt <djurfeldt@nada.kth.se> * hashtab.c, hashtab.h (scm_hash_map_to_list): Renamed from scm_hash_map. 2004-02-12 Mikael Djurfeldt <djurfeldt@nada.kth.se> * boot-9.scm (module-map): Renamed hash-map -> hash-map->list. M _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2004-02-13 23:22 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2004-01-24 13:19 About hash-table iterators Roland Orre 2004-01-27 16:07 ` Mikael Djurfeldt 2004-01-27 17:39 ` Roland Orre 2004-02-13 23:22 ` Mikael Djurfeldt
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).