guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Daniel Hartwig
Subject: Re: [PATCH] Add-native-hashtable-helper-functions
Date: Wed, 27 Mar 2013 13:10:58 +0800

On 27 March 2013 08:47, Nala Ginrut <address@hidden> wrote:
>
> 在 2013-3-27 AM5:59,"Ludovic Courtès" <address@hidden>写道:
>
>
>>
>> Nala Ginrut <address@hidden> 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’.
>>
>>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]