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:14:14 -0200 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000000eec4a057fade1e5" X-Trace: blaine.gmane.org 1547759574 16330 195.159.176.226 (17 Jan 2019 21:12:54 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 17 Jan 2019 21:12:54 +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:12:50 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 1gkEy1-00047f-RK for guile-devel@m.gmane.org; Thu, 17 Jan 2019 22:12:50 +0100 Original-Received: from localhost ([127.0.0.1]:55026 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gkF08-0000OQ-SB for guile-devel@m.gmane.org; Thu, 17 Jan 2019 16:15:00 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:35119) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gkEzq-0000Mi-V9 for guile-devel@gnu.org; Thu, 17 Jan 2019 16:14:44 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gkEzp-0004fe-BB for guile-devel@gnu.org; Thu, 17 Jan 2019 16:14:42 -0500 Original-Received: from mail-it1-x132.google.com ([2607:f8b0:4864:20::132]:52176) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gkEzg-0004Pz-IU; Thu, 17 Jan 2019 16:14:33 -0500 Original-Received: by mail-it1-x132.google.com with SMTP id w18so3748649ite.1; Thu, 17 Jan 2019 13:14:26 -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=XOFV3wEVDBGCQ1r9SusR2A7acQPALrYjUnYXaWBQQlE=; b=q43l1UuwEJs3s+s2aVJtHylUdiDTlAoORORfQRfNvmZNqL2VCxfKFWTz95zMCQBuLw COZMGaYBxfH9tQYZQZGm1Qx4zvANViyE/27K/hCBppgHsVaWPJlQuxu2h0qgtf0LCYjB +jFfntmwsUaQxGQeDmv4/+usjF4N4NpPux9pcFVlnVYw9K5j2OWywGFWkRCH2Eq/KfHK gGvM2sChs+JTjd0eOWG2+k0VOnll+SH4Tja14dm/gWNhSM7nxQ6Dy3bN4xJTKXg8vNUY OOWBZcsRBfgwdEAGD66KxQLoyT4y6JrClXRxPlEedq6cBdWdH8NgDOpliBPLyaEYN2Xg jkKA== 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=XOFV3wEVDBGCQ1r9SusR2A7acQPALrYjUnYXaWBQQlE=; b=uRHRtW/DhkV9izYKaYetPodSL1xHy5ztMQuyFWKbdP2TghKvAvI8Wy61mXxpcyD4+v DZ6KdqdSfYywPMVXOUQjpN0q4C2T+j5CUzzhr77JSsjNlUJ3oawBe+KZdvGccUo6Rq/H CQtEyiFgyE71bCAJxjWCtVNC7GndQsNss1/kiZSjGO7WihScnll9aK6EGogeiV+tqTwc H7piJl5m+ZausbD6Obw+8qeC+zjHn/o2FsDcTL+doc20JVtkx4nEH4/w4Z69VqQwJdt5 +lgHNBG1LG5tLSifCPZ5tKnVtpuwe9YyLKD3eBqDsDeudEu1WzdKdCjVgooWhdHjWDh3 wUzw== X-Gm-Message-State: AJcUukdVaXvSlVOtixX8n/Jl2ewr+xxIfjYVmO6YYGwdaLTyW3STopER CP0pXeeyFf4bqsa1X5+0xvU6UC9h8apsD4L+/VQ= X-Google-Smtp-Source: ALg8bN6CSV1YQCL6C1+OjT3uOdLOKucMY0aUh1bF2IuObIU77K7FIhIqUL7YboY1raIwKy4/badkK0E562l3pX6Txyk= X-Received: by 2002:a24:6c12:: with SMTP id w18mr10579620itb.14.1547759665472; Thu, 17 Jan 2019 13:14:25 -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::132 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:19797 Archived-At: --0000000000000eec4a057fade1e5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable *Note Em qui, 17 de jan de 2019 =C3=A0s 19:13, J=C3=A9ssica Milar=C3=A9 escreveu: > 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 t= hat >> I can directly comment in the pull requests. please. It's easier to way = to >> 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 an= d >>> 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 HASHTABLE= S), >>>> SRFI-126 and SRFI-125. Since SRFI-125 depends on SRFI-128, I've implem= ented >>>> 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 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 equival= ence >>>> 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 wea= k >>>>> > hash tables - and I've sent a patch to fix it. However, I think the= re >>>>> > 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 tabl= es >>>>> > (which is implemented on top or SRFI-69 and completely lacks suppor= t >>>>> > for weak keys and/or values). >>>>> > >>>>> > I think that should be fixed and guile should have only two kinds o= f >>>>> > hash tables: the standard guile hash table and another extended has= h >>>>> > 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 R7R= S >>>>> > 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 >>>>> >>>> --0000000000000eec4a057fade1e5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
*Note

Em qui, 17 de jan de 2019 =C3=A0s 19:13, J=C3=A9ssica Milar=C3=A9 <jessymilare@gmail.com> escreveu= :
Done.

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

=
=

Em qua, 1= 6 de jan de 2019 =C3=A0s 22:19, Amirouche Boubekki <amirouche.boubekki@gmail.com<= /a>> escreveu:

Le=C2=A0dim. 13 janv. 2019 =C3=A0=C2=A023:52, J=C3=A9ssica Milar=C3=A9 <= ;jessymilare@gma= il.com> a =C3=A9crit=C2=A0:
Finally finished the libraries.
SRFI-125 is implemented. I took the liberty to create a procedu= re scm_hash_n_items in 'libguile/hashtab.c' that works with both no= rmal and weak hash tables, so the GENERIC-HASH-TABLES module don't need= to keep track of the hash table size anymore.

`ma= ke check` runs everything ok. I believe it's ready for testing. Any fee= dback is welcome.

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

Em s=C3=A1b, 12 = de jan de 2019 =C3=A0s 18:34, J=C3=A9ssica Milar=C3=A9 <jessymilare@gmail.com> es= creveu:
(It seems I mistakenly responded only to a personal e-mail, sorry,= responded now to everyone in the list with updates).

So here are th= e 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 HAS= HTABLES), 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'l= l push it as well.

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

Now, I see that 'libguile/hashtab.h' code keeps t= rack 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 ne= ed to also keep track of the number of elements (like SRFI-69 currently doe= s) and that would simplify its code.

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

I've als= o found inconsistencies between SRFI-125 and it's reference implementat= ion and standard tests. I've implemented according to the specification= - so, for instance, HASH-TABLE=3D? checks if the equivalence function of b= oth hash tables are the same and HASH-TABLE returns an immutable hash table= .

Code is public and suggestions are always welcom= e :)

Regargs,
J=C3=A9ssica

Em dom, 30 de dez de 2018 =C3=A0s 15:50, Amirouche Boubek= ki <amirouc= he@hypermove.net> escreveu:
Le 2018-12-28 17:11, J=C3=A9ssica Milar=C3=A9 a =C3=A9cr= it=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
--0000000000000eec4a057fade1e5--