From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Amirouche Boubekki Newsgroups: gmane.lisp.guile.devel Subject: Re: Proposal of a better hash table implementation based on SRFI 125 Date: Thu, 17 Jan 2019 01:18:58 +0100 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000f18ee0057f9c5703" X-Trace: blaine.gmane.org 1547684510 10933 195.159.176.226 (17 Jan 2019 00:21:50 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 17 Jan 2019 00:21:50 +0000 (UTC) Cc: guile-devel , guile-devel , Amirouche Boubekki To: =?UTF-8?B?SsOpc3NpY2EgTWlsYXLDqQ==?= Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Jan 17 01:21:46 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 1gjvRJ-0002hM-R2 for guile-devel@m.gmane.org; Thu, 17 Jan 2019 01:21:46 +0100 Original-Received: from localhost ([127.0.0.1]:42647 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gjvTQ-0006eF-Uc for guile-devel@m.gmane.org; Wed, 16 Jan 2019 19:23:56 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:59767) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gjvOu-0003Dv-VF for guile-devel@gnu.org; Wed, 16 Jan 2019 19:19:18 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gjvOt-0005U4-GP for guile-devel@gnu.org; Wed, 16 Jan 2019 19:19:16 -0500 Original-Received: from mail-vs1-xe2c.google.com ([2607:f8b0:4864:20::e2c]:38103) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gjvOq-0005Lr-5z; Wed, 16 Jan 2019 19:19:12 -0500 Original-Received: by mail-vs1-xe2c.google.com with SMTP id x64so5140742vsa.5; Wed, 16 Jan 2019 16:19:11 -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=/WmJuSPx9QvBOA9h35HRzVcO7RZo2XFR3T/cDiDb+lQ=; b=ejkxyH8rANqQhv3vFBXYVPUtxHRIXwE/45tUTlswbWDHWZkW0AAl8Y3WglFvUw3crJ I3dW7uOPVf2vLLA907Hfv61hWbIkRU5QtrzmBMQ1oJKRGJC+6t7U2kBqkLmtGGjE3nFW so5LfHgQlW4EChOnYcgVLjNOSXy10VATJBkSXmxaPuLvUwtbplyOn3ezjHGXTpnui1Vx zjLWhwftYWZmDIyo3hAESV4a5xXTcSNombaLAmHHmewriFypWVGDZCbr4trlfN251Sjd q0rEzv9L3N9WL0yhO0nqfCFFvdfFDXYKcsfeiAEVQNAKXHsaW0oGK+T8EqsLPwaSfRJg W73g== 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=/WmJuSPx9QvBOA9h35HRzVcO7RZo2XFR3T/cDiDb+lQ=; b=bmvmEGfr1evsAawAcWPEcav2s0/+NzXSEY2HllxBxUnGnoSbcCaW2ZFpd4aL/4ktcZ 1dq1eXwbdeV9uNtH4IptMzdJ6MZ2Mv080JJVnyZBvAoWGlSyLBLrhB0oxoV8mD8X8Dtk KoerNnXbRcFF7wA0jv1a1VheQlbobItIRYQqjx7YxT0dXxcAFfB2BAgPSLm2Xt3HNC/q GdaP65qvNqkG4ABuSVEnAy4oJqP0WNCWlPf6oLL8Ft7M3U60m5d/nzDDpxs3PspWuppo 9sKplbhQOG1IQH3d/j3pE1K+RRFix/s6EaPA8S4gzR/hBR2Yf7wd2ro/ZGBmJ22Ikb1v O21A== X-Gm-Message-State: AJcUukc3YpzstCciAzCgmT56DzRSlP2spNRv3iv7T1g/TrRYmLJ7w7ma /j5ynI/LIOR62Yz4SUQ3r8uVtjWc4legS09FhEk= X-Google-Smtp-Source: ALg8bN4Z1eD3XYimGH8tk0ZBSue1KKOKQKYGJapQ65oeyR4KohTsY3LeBGzNWdw7YkekGcKAgndscQa8XMHOkTReZlg= X-Received: by 2002:a67:fa82:: with SMTP id f2mr4913426vsq.177.1547684350625; Wed, 16 Jan 2019 16:19:10 -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::e2c 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:19793 Archived-At: --000000000000f18ee0057f9c5703 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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 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 > 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 implemen= ted >> it as well. My public repository already has SRFI-128, I'm just finishin= g >> 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 t= hat >> 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 equivalen= ce >> 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 >>> >> --000000000000f18ee0057f9c5703 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 requests. please. It= 's easier to way to see the overall changes in particular.
<= br>
Le=C2= =A0dim. 13 janv. 2019 =C3=A0=C2=A023:52, J=C3=A9ssica Milar=C3=A9 <jessymilare@gmail.com> a =C3=A9c= rit=C2=A0:
Finally finished the libraries.

SRFI-125 is = implemented. I took the liberty to create a procedure scm_hash_n_items in &= #39;libguile/hashtab.c' that works with both normal and weak hash table= s, so the GENERIC-HASH-TABLES module don't need to keep track of the ha= sh table size anymore.

`make check` runs everythin= g ok. I believe it's ready for testing. Any feedback is welcome.
<= div>
Regards,
J=C3=A9ssica

Em s=C3=A1b, 12 de jan de 2019 =C3=A0s 1= 8:34, J=C3=A9ssica Milar=C3=A9 <jessymilare@gmail.com> escreveu:
(It seems I mis= takenly responded only to a personal e-mail, sorry, responded now to everyo= ne 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 SR= FI-125, and used it to implement SRFI-69, (RNRS HASHTABLES), SRFI-126 and S= RFI-125. Since SRFI-125 depends on SRFI-128, I've implemented it as wel= l. My public repository already has SRFI-128, I'm just finishing some t= ests with SRFI-125 and, once they are done, I'll push it as well.
<= br>
The module (ice-9 generic-hash-tables), is quite usable and a= ll exported procedures are documented. I've created tests for it and al= so ported standard tests from SRFI-126.

Now, I= see that 'libguile/hashtab.h' code keeps track of the number of el= ements in hash tables, but the field is not visible from Scheme. Can that b= e 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 simpli= fy its code.

Besides, what about creating new vers= ions HASHX-*=C2=A0procedures that accept an equivalence procedure instead o= f 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, HAS= H-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 :)

Regargs,
J= =C3=A9ssica

Em d= om, 30 de dez de 2018 =C3=A0s 15:50, Amirouche Boubekki <amirouche@hypermove.net&g= t; 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
--000000000000f18ee0057f9c5703--