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: Sun, 13 Jan 2019 20:50:50 -0200 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000002fded3057f5ec339" X-Trace: blaine.gmane.org 1547419839 32634 195.159.176.226 (13 Jan 2019 22:50:39 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 13 Jan 2019 22:50:39 +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 Sun Jan 13 23:50:34 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 1gioaQ-0008LV-5t for guile-devel@m.gmane.org; Sun, 13 Jan 2019 23:50:34 +0100 Original-Received: from localhost ([127.0.0.1]:46385 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1giocX-0007Vn-39 for guile-devel@m.gmane.org; Sun, 13 Jan 2019 17:52:45 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:40060) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1giocM-0007Sr-Ax for guile-devel@gnu.org; Sun, 13 Jan 2019 17:52:37 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gioau-000073-3Z for guile-devel@gnu.org; Sun, 13 Jan 2019 17:51:05 -0500 Original-Received: from mail-io1-xd34.google.com ([2607:f8b0:4864:20::d34]:42911) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gioat-0008TX-Q8; Sun, 13 Jan 2019 17:51:04 -0500 Original-Received: by mail-io1-xd34.google.com with SMTP id x6so16294701ioa.9; Sun, 13 Jan 2019 14:51:02 -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=y+CTBcB9ieO9SWChSrjQxFAH+5xG9N5zHgFBOTVbqQo=; b=Ujvh7GXgQexNG6+6SG/LWDeICCnR6hs75SBMZdJR1oPwA4fi8+45tmq+BPi1hMUIf0 ycKh2YN6IA3t/5EKn8ZYkN3T1AzWnFU5ghgMg4br/j1BDj610sbumipj5Qh0lpN5oG4J gwCeaYjJ61DCvzha9VJqiulWvRzRV2o32SwBXcwLsgeCv9IVcp0i1Iu70S2quVRpNvpH LdG02xIHa1kPoGG42fNTbfnaXp4tSlLtSkO/7zADhJntqwnq2usnAGRez76h22illwAw ke6YElEYLS7dYQiJ21sTQmQnzYmVYuB+TTy++aLyJ36PM26kKs9EbVOKlZenyBQbEBqQ siHw== 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=y+CTBcB9ieO9SWChSrjQxFAH+5xG9N5zHgFBOTVbqQo=; b=lPHTzdCoyQL3VNevICi96tDiNVAtcT8QBmXlaBlcxjqxOz8FGNyw0YUwFbea6Litgu rfVuyz8yYJHQ8U9tKm5p5vOS6EI13j8mB0+S70Mu0GRScdFiphvRLKQdyLkzHofaRz49 q6ADwYqKm1tz7v9g29QrWrawz439c7AIShGCaO7mj65mMOZHzvYMZX5VH8PfDtq9B6+y S2zEsmvIU02KpppTh2IwC4UajrBJ3xJ/V4hak0ypUpzM3y4vGCj8t/MprKs068KTv821 qXUEjvp93RabOI4NXErAep8cRcV1rXtYlE4nhjC8nWaOhZKz/EATsejxTq5QdnDoR84c oLjA== X-Gm-Message-State: AJcUukcdlj08EWXzgANM1uxLe6eua/kZgS3d7u5sdVrM2YPi2WGnq0c2 CNCxFU5SjavPr3zdtWwX9kwBaZxpfPztMLsElzJEew== X-Google-Smtp-Source: ALg8bN6SkxljA/j31yxq9nGmEh+u2xq5FrX5r6QsAva4DbNfQljWakey/BixUTTJoBcl96WxawtD01+aWKed/u6QqWg= X-Received: by 2002:a6b:600b:: with SMTP id r11mr16018741iog.259.1547419861899; Sun, 13 Jan 2019 14:51:01 -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::d34 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:19791 Archived-At: --0000000000002fded3057f5ec339 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 simila= r > to SRFI-125, and used it to implement SRFI-69, (RNRS HASHTABLES), SRFI-12= 6 > 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 th= at > 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 equivalenc= e > 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 >> > --0000000000002fded3057f5ec339 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Finally finished the libraries.

SRFI-12= 5 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 t= he hash table size anymore.

`make check` runs ever= ything 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 re= sponded 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, an= d used it to implement SRFI-69, (RNRS HASHTABLES), SRFI-126 and SRFI-125. S= ince SRFI-125 depends on SRFI-128, I've implemented it as well. My publ= ic 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.

<= div>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 of the numbe= r of elements (like SRFI-69 currently does) and that would simplify its cod= e.

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

I've also found inconsistencies between SR= FI-125 and it's reference implementation and standard tests. I've i= mplemented according to the specification - so, for instance, HASH-TABLE=3D= ? checks if the equivalence function of both hash tables are the same and H= ASH-TABLE returns an immutable hash table.

Code is= public and suggestions are always welcome :)

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

Em dom, 30 de de= z de 2018 =C3=A0s 15:50, Amirouche Boubekki <amirouche@hypermove.net> escreveu:=
Le 2018-12-28 1= 7: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
--0000000000002fded3057f5ec339--