From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: =?UTF-8?B?SsOpc3NpY2EgTWlsYXLDqQ==?= Newsgroups: gmane.lisp.guile.devel Subject: Re: Proposal of a better hash table implementation based on SRFI 125 Date: Sat, 12 Jan 2019 18:34:06 -0200 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000005b21a3057f48bc58" X-Trace: blaine.gmane.org 1547325602 8366 195.159.176.226 (12 Jan 2019 20:40:02 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 12 Jan 2019 20:40:02 +0000 (UTC) Cc: guile-devel , guile-devel@gnu.org To: Amirouche Boubekki Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat Jan 12 21:39:57 2019 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1giQ4T-0001zQ-Hg for guile-devel@m.gmane.org; Sat, 12 Jan 2019 21:39:57 +0100 Original-Received: from localhost ([127.0.0.1]:60807 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1giQ6a-0001Ur-Bk for guile-devel@m.gmane.org; Sat, 12 Jan 2019 15:42:08 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:43964) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1giQ6M-0001GU-Pw for guile-devel@gnu.org; Sat, 12 Jan 2019 15:41:56 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1giPz9-0003fq-Gs for guile-devel@gnu.org; Sat, 12 Jan 2019 15:34:28 -0500 Original-Received: from mail-it1-x12f.google.com ([2607:f8b0:4864:20::12f]:38118) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1giPz7-0003Pn-TH; Sat, 12 Jan 2019 15:34:27 -0500 Original-Received: by mail-it1-x12f.google.com with SMTP id h65so7512266ith.3; Sat, 12 Jan 2019 12:34:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XA46Q8pl4bQEDzJmqxiplR5uU91+TihNTdk3rksWcpE=; b=SWWN7IYYW+64tjvd1gn/F0UCuFM2ZCO+JD80X6P+Y1eDZxZAVLfeEy+MTawwXOYhi9 g6RkTA5IW793z6dzBfsWdRQg2ja2k2M2crZyMxFtfDc9zoYQAJzIaByXzei5oN2V0yhX jhd/cGR95D4P+JDNPw7SjQXNDGCaTQniLdXdWAGaudDUkq/DtC09e7OaH//GVPOaWAna mAVRKzFPUpXnVqJ8R8RFCpgvQpJhxEH6qH9P9dEVFmACAW/v1JFeXkaGsHHi8dXGhuu+ yhdo1k79/CyyTfiHIQV5uCB/q8h5HY3leouiFlU0pCa2TxzVMC+iqLuIHdX1spxTrqiq AVyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XA46Q8pl4bQEDzJmqxiplR5uU91+TihNTdk3rksWcpE=; b=Nkc84ziYn+27bmRgYIU+u7XwaLuTvMxLMDU1cHCdyG6SQWRcvbzlv1bZY10nvwgNMk fQ8wyxedNuzCKUst77UpC8Owurynw2DmDWkjC1HdibkasVjwhbAN/bmhLbhmKXrRhk7X CmAP1Aq3ftnaUvSqcy98Xu4M/FmTuZHn5D62rQIdPGPzva5JO154R3pkrmURIPuHqfTK vofsPPf73EvU1F8RfppCLy7VJQn3X2d1d0JN1XH6Jfox0yRbGxxvDb6F4stipMGks1CO Q/Hp2wVLs6KIPbAvYxSPAiZUWPsFTooVok2KopYoc3YmMXlZDqDD185ufNUjqwgKvLCi 6Hsg== X-Gm-Message-State: AJcUukegYum3QWUdm23GbH5796roRQqI6W5meES+dXhh5P1mq06GOJuX 4WbDODJqkcsQu+gr35oxnlq3HptLGRhXPrqRkbUYXPCL X-Google-Smtp-Source: ALg8bN7V9A2bqxG3TB2lP7I7pqwg2C/juDZ0PM93x8fZGyjuHL9tfvyCJOxlZG+nKZs3Udv3r91PYoMqtxCA3Ha03eE= X-Received: by 2002:a24:6c12:: with SMTP id w18mr5090520itb.14.1547325258013; Sat, 12 Jan 2019 12:34:18 -0800 (PST) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::12f X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: "guile-devel" Xref: news.gmane.org gmane.lisp.guile.devel:19790 Archived-At: --0000000000005b21a3057f48bc58 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable (It seems I mistakenly responded only to a personal e-mail, sorry, responded now to everyone in the list with updates). So here are the news: I've created a module called (ice-9 generic-hash-tables), which is similar to SRFI-125, and used it to implement SRFI-69, (RNRS HASHTABLES), SRFI-126 and SRFI-125. Since SRFI-125 depends on SRFI-128, I've implemented it as well. My public repository already has SRFI-128, I'm just finishing some tests with SRFI-125 and, once they are done, I'll push it as well. The module (ice-9 generic-hash-tables), is quite usable and all exported procedures are documented. I've created tests for it and also ported standard tests from SRFI-126. Now, I see that 'libguile/hashtab.h' code keeps track of the number of elements in hash tables, but the field is not visible from Scheme. Can that be changed? Then generic hash tables wouldn't need to also keep track of the number of elements (like SRFI-69 currently does) and that would simplify its code. Besides, what about creating new versions HASHX-* procedures that accept an equivalence procedure instead of an assoc procedure? Perhaps prefixed by 'NEW-' or post-fixed by a '*'. I've also found inconsistencies between SRFI-125 and it's reference implementation and standard tests. I've implemented according to the specification - so, for instance, HASH-TABLE=3D? checks if the equivalence function of both hash tables are the same and HASH-TABLE returns an immutable hash table. Code is public and suggestions are always welcome :) https://github.com/jessymilare/guile Regargs, J=C3=A9ssica Em dom, 30 de dez de 2018 =C3=A0s 15:50, Amirouche Boubekki < amirouche@hypermove.net> escreveu: > Le 2018-12-28 17:11, J=C3=A9ssica Milar=C3=A9 a =C3=A9crit : > > Hello, > > > > As I said in a previous e-mail, currently SRFI-69 is broken for weak > > hash tables - and I've sent a patch to fix it. However, I think there > > are many other problems with current implementation of hash tables. > > There are guile standard hash tables, SRFI-69 hash tables (which is > > implemented on top of standard hash tables) and also R6RS hash tables > > (which is implemented on top or SRFI-69 and completely lacks support > > for weak keys and/or values). > > > > I think that should be fixed and guile should have only two kinds of > > hash tables: the standard guile hash table and another extended hash > > table type that will be used directly by R6RS, SRFI-125 and SRFI-69. > > In my opinion, it should be based on SRFI-125, which is part of R7RS > > Red Edition, but also supports some other procedures to make it > > compatible with R6RS and SRFI-69, supporting weakness and immutable > > hash tables. > > > > I'm already implementing the SRFI-125 based hash tables library for > > myself, so, if that is accepted, I can also make a patch for guile. > > > > Yes please make a patch and attach it to the bug report. > > Don't forget to send an announcement when you SRFI-125 implementation > is ready for testing. Is it already available anywhere? > > TIA > --0000000000005b21a3057f48bc58 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(It seems I mistakenly responded only to a personal e-mail= , sorry, responded now to everyone in the list with updates).

So her= e are the news:

I've created a module called (ice-9 generic-hash= -tables), which is similar to SRFI-125, and used it to implement SRFI-69, (= RNRS HASHTABLES), SRFI-126 and SRFI-125. Since SRFI-125 depends on SRFI-128= , I've implemented it as well. My public repository already has SRFI-12= 8, I'm just finishing some tests with SRFI-125 and, once they are done,= I'll push it as well.

The module (ice-9 generic-has= h-tables), is quite usable and all exported procedures are documented. I= 9;ve created tests for it and also ported standard tests from SRFI-126.
=

Now, I see that 'libguile/hashtab.h' code= keeps track of the number of elements in hash tables, but the field is not= visible from Scheme. Can that be changed? Then generic hash tables wouldn&= #39;t need to also keep track of the number of elements (like SRFI-69 curre= ntly does) and that would simplify its code.

Besid= es, what about creating new versions HASHX-*=C2=A0procedures that accept an= equivalence procedure instead of an assoc procedure? Perhaps prefixed by &= #39;NEW-' or post-fixed by a '*'.

I= 9;ve also found inconsistencies between SRFI-125 and it's reference imp= lementation and standard tests. I've implemented according to the speci= fication - so, for instance, HASH-TABLE=3D? checks if the equivalence funct= ion of both hash tables are the same and HASH-TABLE returns an immutable ha= sh table.

Code is public and suggestions are alway= s welcome :)

<= /div>
Regargs,
J=C3=A9ssica

Em dom, 30 de dez de 2018 =C3=A0s 15:50, Amirouch= e Boubekki <amirouche@hypermo= ve.net> escreveu:
Le 2018-12-28 17:11, J=C3=A9ssica Milar=C3=A9 a =C3=A9crit=C2=A0= :
> Hello,
>
> As I said in a previous e-mail, currently SRFI-69 is broken for weak > hash tables - and I've sent a patch to fix it. However, I think th= ere
> are many other problems with current implementation of hash tables. > There are guile standard hash tables, SRFI-69 hash tables (which is > implemented on top of standard hash tables) and also R6RS hash tables<= br> > (which is implemented on top or SRFI-69 and completely lacks support > for weak keys and/or values).
>
> I think that should be fixed and guile should have only two kinds of > hash tables: the standard guile hash table and another extended hash > table type that will be used directly by R6RS, SRFI-125 and SRFI-69. > In my opinion, it should be based on SRFI-125, which is part of R7RS > Red Edition, but also supports some other procedures to make it
> compatible with R6RS and SRFI-69, supporting weakness and immutable > hash tables.
>
> I'm already implementing the SRFI-125 based hash tables library fo= r
> myself, so, if that is accepted, I can also make a patch for guile. >

Yes please make a patch and attach it to the bug report.

Don't forget to send an announcement when you SRFI-125 implementation is ready for testing. Is it already available anywhere?

TIA
--0000000000005b21a3057f48bc58--