About hash-table iterators

About hash-table iterators

[Roland Orre]

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

Re: About hash-table iterators

[Mikael Djurfeldt]

[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

Re: About hash-table iterators

[Roland Orre]

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

Re: About hash-table iterators

[Mikael 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