[PATCH] Add-native-hashtable-helper-functions

[PATCH] Add-native-hashtable-helper-functions

[Nala Ginrut]

[-- Attachment #1: Type: text/plain, Size: 285 bytes --]

Added three helper functions, they're so explicit that don't need any
docs in the manual I think. Docstring is enough.

* hash-items: get the amount of items in the hash table
* hash-size: return the size of hash table
* hash-keys: return all the keys of hash table as a list

Thanks!

[-- Attachment #2: 0001-Add-native-hashtable-helper-functions.patch --]
[-- Type: text/x-patch, Size: 2423 bytes --]

From 167e82e93ee59ac9a0244006ae9664d68877b4c8 Mon Sep 17 00:00:00 2001
From: Nala Ginrut <nalaginrut@gmail.com>
Date: Tue, 26 Mar 2013 16:00:54 +0800
Subject: [PATCH] Add native hashtable helper functions.

libguile/hashtab.c: Add hash-items and hash-size
libguile/hashtab.h

module/ice-9/boot-9.scm: Add hash-keys
---
 libguile/hashtab.c      |   19 +++++++++++++++++++
 libguile/hashtab.h      |    2 ++
 module/ice-9/boot-9.scm |    8 ++++++++
 3 files changed, 29 insertions(+)

diff --git a/libguile/hashtab.c b/libguile/hashtab.c
index 88cb199..b1e59b8 100644
--- a/libguile/hashtab.c
+++ b/libguile/hashtab.c
@@ -383,6 +383,25 @@ scm_i_rehash (SCM table,
     }
 }
 
+SCM_DEFINE (scm_hash_items, "hash-items", 1, 0, 0,
+            (SCM table),
+            "Get the amount of items in this hash table.")
+#define FUNC_NAME s_scm_hash_items
+{
+  SCM_VALIDATE_HASHTABLE (1, table);
+  return scm_from_uint (SCM_HASHTABLE_N_ITEMS (table));
+}
+#undef FUNC_NAME
+
+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)));
+}
+#undef FUNC_NAME
 
 void
 scm_i_hashtable_print (SCM exp, SCM port, scm_print_state *pstate)
diff --git a/libguile/hashtab.h b/libguile/hashtab.h
index dcebcb8..227299e 100644
--- a/libguile/hashtab.h
+++ b/libguile/hashtab.h
@@ -96,6 +96,8 @@ typedef struct scm_t_hashtable {
 
 SCM_API SCM scm_vector_to_hash_table (SCM vector);
 SCM_API SCM scm_c_make_hash_table (unsigned long k);
+SCM_API SCM scm_hash_table_size (SCM h);
+SCM_API SCM scm_hash_table_items (SCM h);
 SCM_API SCM scm_make_hash_table (SCM n);
 SCM_API SCM scm_make_weak_key_hash_table (SCM k);
 SCM_API SCM scm_make_weak_value_hash_table (SCM k);
diff --git a/module/ice-9/boot-9.scm b/module/ice-9/boot-9.scm
index ced3a28..ae1c49b 100644
--- a/module/ice-9/boot-9.scm
+++ b/module/ice-9/boot-9.scm
@@ -34,6 +34,14 @@
 
 \f
 
+;; Native hash-table helper functions.
+
+(define (hash-keys table)
+  "Return all the keys from hash table."
+  (hash-map->list (lambda (x y) x) table))
+
+\f
+
 ;; Before compiling, make sure any symbols are resolved in the (guile)
 ;; module, the primary location of those symbols, rather than in
 ;; (guile-user), the default module that we compile in.
-- 
1.7.10.4

Re: [PATCH] Add-native-hashtable-helper-functions

[Noah Lavine]

[-- Attachment #1: Type: text/plain, Size: 538 bytes --]

I would be afraid that without an entry in the manual, people won't know
the functions exist, even if the docstrings are enough to explain what they
do.

Noah


On Tue, Mar 26, 2013 at 6:40 AM, Nala Ginrut <nalaginrut@gmail.com> wrote:

> Added three helper functions, they're so explicit that don't need any
> docs in the manual I think. Docstring is enough.
>
> * hash-items: get the amount of items in the hash table
> * hash-size: return the size of hash table
> * hash-keys: return all the keys of hash table as a list
>
> Thanks!
>

[-- Attachment #2: Type: text/html, Size: 901 bytes --]

Re: [PATCH] Add-native-hashtable-helper-functions

[Ludovic Courtès]

Nala Ginrut <nalaginrut@gmail.com> skribis:

> * hash-items: get the amount of items in the hash table

There’s already ‘hash-count’, recently added.

> +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.

> +(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?

Thanks,
Ludo’.

Re: [PATCH] Add-native-hashtable-helper-functions

[Nala Ginrut]

[-- Attachment #1: Type: text/plain, Size: 1321 bytes --]

在 2013-3-27 AM5:59，"Ludovic Courtès" <ludo@gnu.org>写道：
>
> Nala Ginrut <nalaginrut@gmail.com> skribis:
>
> > * 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.

> > +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.

> > +(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.

> Thanks,
> Ludo’.
>
>

[-- Attachment #2: Type: text/html, Size: 1823 bytes --]

Re: [PATCH] Add-native-hashtable-helper-functions

[Daniel Hartwig]

On 27 March 2013 08:47, Nala Ginrut <nalaginrut@gmail.com> wrote:
>
> 在 2013-3-27 AM5:59，"Ludovic Courtès" <ludo@gnu.org>写道：
>
>
>>
>> Nala Ginrut <nalaginrut@gmail.com> 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.

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.)

>> > +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’.
>>
>>

Re: [PATCH] Add-native-hashtable-helper-functions

[Nala Ginrut]

On Wed, 2013-03-27 at 13:10 +0800, Daniel Hartwig wrote:
> On 27 March 2013 08:47, Nala Ginrut <nalaginrut@gmail.com> wrote:
> >
> > 在 2013-3-27 AM5:59，"Ludovic Courtès" <ludo@gnu.org>写道：
> >
> >
> >>
> >> Nala Ginrut <nalaginrut@gmail.com> 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’.
> >>
> >>

Re: [PATCH] Add-native-hashtable-helper-functions

[Daniel Hartwig]

On 27 March 2013 14:32, Nala Ginrut <nalaginrut@gmail.com> wrote:
> On Wed, 2013-03-27 at 13:10 +0800, Daniel Hartwig wrote:
>> On 27 March 2013 08:47, Nala Ginrut <nalaginrut@gmail.com> wrote:
>> >
>> > 在 2013-3-27 AM5:59，"Ludovic Courtès" <ludo@gnu.org>写道：
>> >
>> >
>> >>
>> >> Nala Ginrut <nalaginrut@gmail.com> 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?

No.  I offer only the vague notion that if this is critical to a
program or some part, it is time to seriously reexamine the design of
that.

The concept of “number of items” is not well defined for
dictionaries.  Do you currently mean:

- number of key–value associations;
- number of unique key–value associations;
- number of unique values;
- number of unique keys.

The answer changes depending on the task at hand.  The ability to
compute any of those numbers varies wildly amongst the possible
implementations.  As an internal detail of the _current_
‘make-hash-table’ in Guile, the first, second, and forth definition
are equivalent and can be determined in constant time.  For alist
and vhash, none of those are equivalent.

In the previous discussion, the motivating example used ‘hash-count’
to test for a condition in a way that was simultaneously unreliable
and difficult to verify.  Refactoring to avoid that would certainly
yield an algorithm without one or the other of those undesirable
traits.  Though I only made a solitary and rough attempt at
demonstrating this, the revised design had a better worse-case
complexity and was reliable.

An other, less “essential” use was completely superficial:

 (if (not (zero? (hash-count (identity #t) t)))
     (hash-for-each proc t))

which, except for any time spent counting, is equivalent to:

 (hash-for-each proc t)

> 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.

For these particular procedures, I would put it more like:

 we do not supply those because all they do is shoot your feet.

>
> 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.

Alas, not just _any_ implementation can provide these.  By coincidence,
_one_ of Guile's can, but do not be fooled: this is not useful
information for an application to have.  If your application needs (?)
this to perform well, or to function at all, there is a much better
way to achieve the same result.  Guaranteed.

Likewise for ‘hash-keys’.

Perhaps you like to point out some code where you feel this is
essential?

Regards

Re: [PATCH] Add-native-hashtable-helper-functions

[Nala Ginrut]

hi Daniel!
First, I'll appreciate your patience. ;-) 

On Wed, 2013-03-27 at 16:55 +0800, Daniel Hartwig wrote:
> On 27 March 2013 14:32, Nala Ginrut <nalaginrut@gmail.com> wrote:
> > On Wed, 2013-03-27 at 13:10 +0800, Daniel Hartwig wrote:
> >> On 27 March 2013 08:47, Nala Ginrut <nalaginrut@gmail.com> wrote:
> >> >
> >> > 在 2013-3-27 AM5:59，"Ludovic Courtès" <ludo@gnu.org>写道：
> >> >
> >> >
> >> >>
> >> >> Nala Ginrut <nalaginrut@gmail.com> 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?
> 
> No.  I offer only the vague notion that if this is critical to a
> program or some part, it is time to seriously reexamine the design of
> that.
> 
> The concept of “number of items” is not well defined for
> dictionaries.  Do you currently mean:
> 
> - number of key–value associations;
> - number of unique key–value associations;
> - number of unique values;
> - number of unique keys.
> 
> The answer changes depending on the task at hand.  The ability to
> compute any of those numbers varies wildly amongst the possible
> implementations.  As an internal detail of the _current_
> ‘make-hash-table’ in Guile, the first, second, and forth definition
> are equivalent and can be determined in constant time.  For alist
> and vhash, none of those are equivalent.
> 
> In the previous discussion, the motivating example used ‘hash-count’
> to test for a condition in a way that was simultaneously unreliable
> and difficult to verify.  Refactoring to avoid that would certainly
> yield an algorithm without one or the other of those undesirable
> traits.  Though I only made a solitary and rough attempt at
> demonstrating this, the revised design had a better worse-case
> complexity and was reliable.
> 
> An other, less “essential” use was completely superficial:
> 
>  (if (not (zero? (hash-count (identity #t) t)))
>      (hash-for-each proc t))
> 

All right, I found this string in the manual:
---------------------------cut-----------------------
To quickly determine the total number of elements, 
use `(const #t)' for PRED.
---------------------------end-----------------------

So we don't need hash-items anymore. ;-P
And sorry for bother since it's too new that I don't familiar with it.
Since it's in-explicit for such a function, how about add:

(define (hash-items ht) (hash-count (const #t) ht))


> which, except for any time spent counting, is equivalent to:
> 
>  (hash-for-each proc t)
> 
> > 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.
> 
> For these particular procedures, I would put it more like:
> 
>  we do not supply those because all they do is shoot your feet.
> 
> >
> > 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.
> 
> Alas, not just _any_ implementation can provide these.  By coincidence,
> _one_ of Guile's can, but do not be fooled: this is not useful
> information for an application to have.  If your application needs (?)
> this to perform well, or to function at all, there is a much better
> way to achieve the same result.  Guaranteed.
> 
> Likewise for ‘hash-keys’.
> 
> Perhaps you like to point out some code where you feel this is
> essential?
> 

Well, I can't say hash-keys is very common though I used it. I suggest
add it just because I found Racket has it. That makes me guess it's
common for others.

And for hash-size, I know a way to detect it with hash-count, since our
native hash-table size grows according to a given "steps table".
I suggest it because I thought users can't get this info unless guile
core export it.

> Regards

Re: [PATCH] Add-native-hashtable-helper-functions

[Ludovic Courtès]

Hi!

Nala Ginrut <nalaginrut@gmail.com> skribis:

> Well, could you point me out how can I get the amount of items with
> hash-count in constant time?

You can’t, but Daniel is arguing that this should not be needed in the
first place, which makes sense to me.

> IMO, return the count of inner record is most explicit way.

As an added complication, it would be inaccurate for weak hash tables.

Ludo’.

Re: [PATCH] Add-native-hashtable-helper-functions

[Mark H Weaver]

ludo@gnu.org (Ludovic Courtès) writes:

> Nala Ginrut <nalaginrut@gmail.com> skribis:
>
>> +(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?

FWIW, I think it would be reasonable to add 'hash-keys'.  Many users
are accustomed to writing in a style that's made more convenient by
'hash-keys', and in cases where efficiency is not crucial, I think
it's a fine style.  Also, sometimes the values aren't needed.

IMO, we can afford to add a few conveniences such as this.

      Mark

Re: [PATCH] Add-native-hashtable-helper-functions

[Nala Ginrut]

[-- Attachment #1: Type: text/plain, Size: 953 bytes --]

On Wed, Mar 27, 2013 at 9:33 PM, Mark H Weaver <mhw@netris.org> wrote:

> ludo@gnu.org (Ludovic Courtès) writes:
>
> > Nala Ginrut <nalaginrut@gmail.com> skribis:
> >
> >> +(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?
>
> FWIW, I think it would be reasonable to add 'hash-keys'.  Many users
> are accustomed to writing in a style that's made more convenient by
> 'hash-keys', and in cases where efficiency is not crucial, I think
> it's a fine style.  Also, sometimes the values aren't needed.
>
> IMO, we can afford to add a few conveniences such as this.
>
>
Thanks for saying that.
And please consider 'hash-items' implemented with hash-count, it's common
as well.

And I'm not sure about hash-size myself, I won't insist on it.

Thanks!


>       Mark
>
>

[-- Attachment #2: Type: text/html, Size: 2321 bytes --]

Re: [PATCH] Add-native-hashtable-helper-functions

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Nala Ginrut <nalaginrut@gmail.com> skribis:
>>
>>> +(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?
>
> FWIW, I think it would be reasonable to add 'hash-keys'.  Many users
> are accustomed to writing in a style that's made more convenient by
> 'hash-keys', and in cases where efficiency is not crucial, I think
> it's a fine style.  Also, sometimes the values aren't needed.
>
> IMO, we can afford to add a few conveniences such as this.

Yes, I agree with this statement.  It turns out that I don’t see
how/when one would use ‘hash-keys?’.  Any examples?

No strong feeling about this one anyway, so if you think it makes sense,
that’s fine with me.

Ludo’.