GNU bug report logs - #10621
Incorrect usage of hash procedures in (ice-9 mapping)

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 10621 in the body.
You can then email your comments to 10621 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Mark H Weaver <mhw <at> netris.org>
To: bug-guile <at> gnu.org
Subject: Incorrect usage of hash procedures in (ice-9 mapping)
Date: Fri, 27 Jan 2012 03:25:15 -0500

These are genuine errors:

ice-9/mapping.scm:97:48: warning: possibly wrong number of arguments to `hashx-get-handle'
ice-9/mapping.scm:94:48: warning: possibly unbound variable `hashx-create-handle'

     Mark

Message #8 received at 10621 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Hartwig <mandyke <at> gmail.com>
To: 10621 <at> debbugs.gnu.org
Cc: Mark H Weaver <mhw <at> netris.org>
Subject: Re: Bug#10621: Incorrect usage of hash procedures in (ice-9 mapping)
Date: Wed, 28 Nov 2012 23:56:43 +0800

Mark H Weaver <mhw <at> netris.org> wrote:
> ice-9/mapping.scm:97:48: warning: possibly wrong number of arguments to `hashx-get-handle'
> ice-9/mapping.scm:94:48: warning: possibly unbound variable `hashx-create-handle'

This module is quite ancient, and, in addition to these warnings, has
not worked for some time.  Some logic errors in hash-table-mapping
(detecting len) and mapping-ref (detecting dflt), for example.  Since
noone has reported the brokenness I guess that means the module has no
users.

There is no practical way to accomodate a separate delete-proc, as
hashx-remove! uses assoc.  The use of delq! and others to convey the
intended delete semantics is incorrect, since mapping-remove! actually
presents and expects a different interface, that of hashq-remove!.

There is no documentation.

It seems the main purpose of this module is to associate hash and assoc
procedures with a hash table, and so provide a single set of accessors
(rather than one for each of hashq, hashv, etc.).  This is more-or-less
handled by both srfi-69 and rnrs hashtables.

A short module, it is not hard to fix, though given all of the above it
makes sense to simply remove it.

Message #11 received at 10621 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Hartwig <mandyke <at> gmail.com>
To: 10621 <at> debbugs.gnu.org
Subject: Re: bug#10621: Incorrect usage of hash procedures in (ice-9 mapping)
Date: Thu, 29 Nov 2012 00:32:09 +0800

[Message part 1 (text/plain, inline)]

On 28 November 2012 23:56, Daniel Hartwig <mandyke <at> gmail.com> wrote:
> A short module, it is not hard to fix

I was after a ten minute distraction, so tackled this.  See attached.

[0001-fix-and-update-ice-9-mapping.patch (application/octet-stream, attachment)]

Message #16 received at 10621-done <at> debbugs.gnu.org (full text, mbox):

From: Andy Wingo <wingo <at> pobox.com>
To: Daniel Hartwig <mandyke <at> gmail.com>
Cc: 10621-done <at> debbugs.gnu.org
Subject: Re: bug#10621: Incorrect usage of hash procedures in (ice-9 mapping)
Date: Sun, 24 Feb 2013 15:10:21 +0100

On Wed 28 Nov 2012 16:56, Daniel Hartwig <mandyke <at> gmail.com> writes:

> A short module, it is not hard to fix, though given all of the above it
> makes sense to simply remove it.

I think removing it is the right thing.  Even with your patch it still
won't work because the default "table constructor" is a vector instead
of a hash table.

Regardless of whether it were new or old, I would much prefer to remove
this module than to document it properly, especially given the existence
of alternatives like srfi-69 and rnrs hash tables as you mention.

I will apply your patch (so that the compile warnings go away), add a
deprecation notice, and remove the module in master.

Andy
-- 
http://wingolog.org/

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.