From: Daniel Hartwig <mandyke@gmail.com>
To: Nala Ginrut <nalaginrut@gmail.com>
Cc: "Ludovic Courtès" <ludo@gnu.org>, guile-devel <guile-devel@gnu.org>
Subject: Re: [PATCH] Add-native-hashtable-helper-functions
Date: Wed, 27 Mar 2013 13:10:58 +0800 [thread overview]
Message-ID: <CAN3veRfQbE8Kegz=oh8ErHWyXx1VEcri4=TX+3hGJ+CwA2if-Q@mail.gmail.com> (raw)
In-Reply-To: <CAPjoZof1M67mjCyd73eigQy11AbfueqW2nNdxfETgqquPLrqxw@mail.gmail.com>
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’.
>>
>>
next prev parent reply other threads:[~2013-03-27 5:10 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-26 10:40 [PATCH] Add-native-hashtable-helper-functions Nala Ginrut
2013-03-26 12:54 ` Noah Lavine
2013-03-26 21:58 ` Ludovic Courtès
2013-03-27 0:47 ` Nala Ginrut
2013-03-27 5:10 ` Daniel Hartwig [this message]
2013-03-27 6:32 ` Nala Ginrut
2013-03-27 8:55 ` Daniel Hartwig
2013-03-27 10:25 ` Nala Ginrut
2013-03-27 10:03 ` Ludovic Courtès
2013-03-27 13:33 ` Mark H Weaver
2013-03-27 13:55 ` Nala Ginrut
2013-03-27 20:21 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAN3veRfQbE8Kegz=oh8ErHWyXx1VEcri4=TX+3hGJ+CwA2if-Q@mail.gmail.com' \
--to=mandyke@gmail.com \
--cc=guile-devel@gnu.org \
--cc=ludo@gnu.org \
--cc=nalaginrut@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).