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

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