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: Thu, 17 Jan 2019 19:13:26 -0200 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000002f2239057faddee3" X-Trace: blaine.gmane.org 1547759524 11757 195.159.176.226 (17 Jan 2019 21:12:04 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 17 Jan 2019 21:12:04 +0000 (UTC) Cc: guile-devel , guile-devel , Amirouche Boubekki To: Amirouche Boubekki Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Jan 17 22:11:59 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 1gkExC-0002sm-0A for guile-devel@m.gmane.org; Thu, 17 Jan 2019 22:11:58 +0100 Original-Received: from localhost ([127.0.0.1]:55023 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gkEzI-0008JU-Tl for guile-devel@m.gmane.org; Thu, 17 Jan 2019 16:14:08 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:34930) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gkEz1-0008IA-V5 for guile-devel@gnu.org; Thu, 17 Jan 2019 16:13:53 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gkEz0-0003in-DX for guile-devel@gnu.org; Thu, 17 Jan 2019 16:13:51 -0500 Original-Received: from mail-io1-xd2a.google.com ([2607:f8b0:4864:20::d2a]:42569) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gkEyw-0003ZS-Fl; Thu, 17 Jan 2019 16:13:46 -0500 Original-Received: by mail-io1-xd2a.google.com with SMTP id x6so8988817ioa.9; Thu, 17 Jan 2019 13:13:38 -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=zfXqAmJ0FFRUZhRESeba/s27did2qWOij/bBv0fJ+PY=; b=aDRItMymSxf5BXmVgDU/k6YCx7Ug+JbdcCDzfUbklMyfZu2q5PDtTc04hivOnjNKgG uqQJ2kGmO1NkN8bTGSV9txD4WqnhFAWb6NB8+SnohF8fAP93jm+oiqn9irFffoIh78X4 1TkF5kgwtyj/4CR18wRmMHyU8EUaqfxsx5akZvUd7cqjlVSQV/k5BHdKjbPxUe0LH3qx TO8WP6vQdvjWRHF0E+KOKB9OkHr4T7VFaxE/AYVf0Rmy6b24+zpDO3gZWQnkKYGGrDdE 6D0Lzj4RszMPGUhoN1Hx+56sPkCR6KItjaZnaMKcP8DeOy75CNG9MVR9FwgThsKFOgam wVbA== 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=zfXqAmJ0FFRUZhRESeba/s27did2qWOij/bBv0fJ+PY=; b=nie5WBY2H5vRILl9OEf/WmCAFUI2CF+qRhoWXLlXyRh1Di+asXt34ue7ffs40GTAGu 1PChy4OjEJccHBd9CSayMCyLWOXm3C/fpZV8SUZAFKukFwe2RLoW4V+YySQPBiL/iAyz QRA+T92VVeTlfDavm0OTAENS/qLbbvyKoH//dwAwhOnpFPpiZ41mGscZo1JMdIVXiI/R PgPyNDZL9cNMXB212iLVKnqMWm0vTovb8393FbYu0JzyYVVQ67M6J116obTUO7z7S05G Y7RFpupCDAE9c3z5eMoZ3/XrPLgOz4YLhZ6FagrwxbzaxKE/3LTifUfrFUqrAt1rzynZ nZ+Q== X-Gm-Message-State: AJcUukffrayZ2kmTwVHf+hB6jOPwvPc7AmuyHbfWOU4zC8bc3NH6l5/n iLxWCVXk/ia/uLVo2d3ghf9buzxDm+YzY7VD24k= X-Google-Smtp-Source: ALg8bN4l7cNhLsdzW1qi4UYVu2bU4eD8xPkICp0nZ7nOMukdcPbPMkGG2ZMnjuHNYdv8E5Vyu4PHK3q8x9+pHYNpb+I= X-Received: by 2002:a6b:156:: with SMTP id 83mr8481387iob.63.1547759617252; Thu, 17 Jan 2019 13:13:37 -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::d2a 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:19796 Archived-At: --0000000000002f2239057faddee3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Done. Not that there are many commits. The first commit only fixes bug 33827 of SRFI 69, and SRFI 69 is reimplemented in the third commit, which pretty much erases the changes of the first commit. https://github.com/jessymilare/guile/pull/1 Em qua, 16 de jan de 2019 =C3=A0s 22:19, Amirouche Boubekki < amirouche.boubekki@gmail.com> escreveu: > I will try to look at the commits. One last niptick, can you push guile > master branch to you repository, and make a pull request against it so th= at > I can directly comment in the pull requests. please. It's easier to way t= o > see the overall changes in particular. > > Le dim. 13 janv. 2019 =C3=A0 23:52, J=C3=A9ssica Milar=C3=A9 a > =C3=A9crit : > >> Finally finished the libraries. >> >> SRFI-125 is implemented. I took the liberty to create a procedure >> scm_hash_n_items in 'libguile/hashtab.c' that works with both normal and >> weak hash tables, so the GENERIC-HASH-TABLES module don't need to keep >> track of the hash table size anymore. >> >> `make check` runs everything ok. I believe it's ready for testing. Any >> feedback is welcome. >> >> Regards, >> J=C3=A9ssica >> >> Em s=C3=A1b, 12 de jan de 2019 =C3=A0s 18:34, J=C3=A9ssica Milar=C3=A9 <= jessymilare@gmail.com> >> escreveu: >> >>> (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 impleme= nted >>> it as well. My public repository already has SRFI-128, I'm just finishi= ng >>> 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 exporte= d >>> 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 o= f >>> the number of elements (like SRFI-69 currently does) and that would >>> simplify its code. >>> >>> Besides, what about creating new versions HASHX-* procedures that accep= t >>> an equivalence procedure instead of an assoc procedure? Perhaps prefixe= d 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 equivale= nce >>> 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 ther= e >>>> > 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 table= s >>>> > (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 >>>> >>> --0000000000002f2239057faddee3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Done.

Not that there are many commits. The first c= ommit only fixes bug=C2=A033827 of SRFI 69, and SRFI 69 is reimplemented in= the third commit, which pretty much erases the changes of the first commit= .


Em qua, 16 de jan de 2019 =C3=A0s 22:19, Amirouche Boubekki <amirouche.boubek= ki@gmail.com> escreveu:
I will try to look at the commits. One= last niptick, can you push guile master branch to you repository, and make= a pull request against it so that I can directly comment in the pull reque= sts. please. It's easier to way to see the overall changes in particula= r.

Le=C2=A0dim. = 13 janv. 2019 =C3=A0=C2=A023:52, J=C3=A9ssica Milar=C3=A9 <jessymilare@gmail.com>= a =C3=A9crit=C2=A0:
Finally finished the libraries.

SR= FI-125 is implemented. I took the liberty to create a procedure scm_hash_n_= items in 'libguile/hashtab.c' that works with both normal and weak = hash tables, so the GENERIC-HASH-TABLES module don't need to keep track= of the hash table size anymore.

`make check` runs= everything ok. I believe it's ready for testing. Any feedback is welco= me.

Regards,
J=C3=A9ssica
Em s=C3=A1b, 12 de jan de 2019= =C3=A0s 18:34, J=C3=A9ssica Milar=C3=A9 <jessymilare@gmail.com> escreveu:
(It s= eems 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 sim= ilar 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 finish= ing some tests with SRFI-125 and, once they are done, I'll push it as w= ell.

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

<= div>Now, I see that 'libguile/hashtab.h' code keeps track of the nu= mber 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 kee= p track of the number of elements (like SRFI-69 currently does) and that wo= uld simplify its code.

Besides, what about creatin= g new versions HASHX-*=C2=A0procedures that accept an equivalence procedure= instead of an assoc procedure? Perhaps prefixed by 'NEW-' or post-= fixed by a '*'.

I've also found incons= istencies between SRFI-125 and it's reference implementation and standa= rd tests. I've implemented according to the specification - so, for ins= tance, HASH-TABLE=3D? checks if the equivalence function of both hash table= s 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.n= et> 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
--0000000000002f2239057faddee3--