From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Mikael Djurfeldt Newsgroups: gmane.lisp.guile.devel Subject: Re: Proposal: Identifier properties for Guile Date: Tue, 17 Sep 2024 10:40:50 +0200 Message-ID: References: <05A7E253-3DFB-4CA8-A257-353BD5FB650F@nonceword.org> Reply-To: mikael@djurfeldt.com Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31840"; mail-complaints-to="usenet@ciao.gmane.io" Cc: guile-devel@gnu.org, Mikael Djurfeldt To: Daphne Preston-Kendal Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Tue Sep 17 10:41:28 2024 Return-path: Envelope-to: guile-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1sqTm3-00087U-Qw for guile-devel@m.gmane-mx.org; Tue, 17 Sep 2024 10:41:27 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sqTlm-0007pX-S6; Tue, 17 Sep 2024 04:41:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sqTlj-0007ba-4E for guile-devel@gnu.org; Tue, 17 Sep 2024 04:41:07 -0400 Original-Received: from mail-vk1-f179.google.com ([209.85.221.179]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sqTlf-0006po-5D for guile-devel@gnu.org; Tue, 17 Sep 2024 04:41:06 -0400 Original-Received: by mail-vk1-f179.google.com with SMTP id 71dfb90a1353d-501213e5ad4so3730627e0c.0 for ; Tue, 17 Sep 2024 01:41:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726562461; x=1727167261; h=content-transfer-encoding:cc:to:subject:message-id:date:from :reply-to:in-reply-to:references:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=ZcO1UWcDisZ5hesBRZeCLJ0gZMMFvluID51XZRSDXi0=; b=dwpEEjJscWXLBBr8tAkC1b/MMzh+ZHnumr+Hsd7MBgwjtyOhZ9Pl1J1iop7vlQdoE8 uied3WK/VP+112bOOifNvFzIz/ruJ5XTiWxrfm6d1PRvhedIYJre/mra2yaqjPsIJq6b gJ3UAyeVoGqiJYsvANrqfbL0sZ1LJ0uay7PXidB41mNqf+otKgqhFoRkLwu1UPYcXYpK ZQyz3b1+ocDNGG1AVbV2Pc+XyOiGUl4Z3JNneAS8lW5WHofs128mgEEg9SO1eBXxQDTD OmYe463VkBJg6upo+P20Kt8JrdMXrnQsddDvLZXCpuZ+8RWI8O8AwMiK3QOBK5MRheUY da7A== X-Gm-Message-State: AOJu0YxtOZyHCPLHX0vyJynz2Pfq30RFoRuknADx549eZNLwsXrCpGo/ AE5wvPUtVQgSjQOLO7j/8fu9qwvpJFBoGmzCx6tatVF4gUwlB8eCtrDsn0ODV+wY7aE1h2/Q+TV zBSYqzd8UMeEgOlx0uDM1xFWVVYI= X-Google-Smtp-Source: AGHT+IGOKodmCSnuPIKiWcJgHIuNOV1lWLxscHMjeGALDPdGojYhf4/YNOitIXM7L2wvHeJCP0/AFQF1lzN+iGkWm1Y= X-Received: by 2002:a05:6122:1da7:b0:502:b69c:b239 with SMTP id 71dfb90a1353d-502f76ba9e2mr22262861e0c.4.1726562461309; Tue, 17 Sep 2024 01:41:01 -0700 (PDT) In-Reply-To: <05A7E253-3DFB-4CA8-A257-353BD5FB650F@nonceword.org> Received-SPF: pass client-ip=209.85.221.179; envelope-from=mdjurfeldt@gmail.com; helo=mail-vk1-f179.google.com X-Spam_score_int: -26 X-Spam_score: -2.7 X-Spam_bar: -- X-Spam_report: (-2.7 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.048, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.lisp.guile.devel:22683 Archived-At: Dear Daphne, What you propose sounds exciting! I also think that you have the right background to pull this off in a nice way. Obviously, Andy Wingo should give his view on this, but I thought that your message should have some response. :-) Best regards, Mikael Djurfeldt On Tue, Sep 10, 2024 at 11:08=E2=80=AFPM Daphne Preston-Kendal wrote: > > Hi! > > I want to implement identifier properties a la SRFI 213 in Guile=E2=80=99= s > psyntax. > > These will be in R7RS Large (in the fascicle on macros coming out Real > Soon Now), and are in fact the only major macro feature Guile is > missing from R7 Large. > > I want to gather feedback on my proposed strategy to implement these > into Guile before starting work. Along the way, I=E2=80=99ll explain some > nuances of the semantics which the SRFI explains very badly (the > fascicle on macros completely redid the text). > > First of all, why would you want identifier properties? As an > admittedly pretty advanced macrologist, I=E2=80=99m convinced these are t= he > best things since sliced bread. I=E2=80=99ve gathered some example use ca= ses > here: > > and in fact the second use case is no longer a hypothetical as it was > when I wrote that page, because I have actually implemented it: > > Getting that library working in Guile and Hoot is my main personal > motivation for wanting this feature =E2=80=93 apart from wanting to see a= n > implementation support the R7-large spec which I wrote ;-) > > Identifier properties are fundamentally very similar to transformer > bindings, and pose some of the same challenges. The main difference is > that identifier properties are attached in addition to a binding, > rather than changing the regular Scheme semantics of the binding. > But like transformer bindings, it makes sense to divide them into > top-level (module-level, in Guile) property definitions and local > definitions. > > The latter are easier to deal with because they don=E2=80=99t need to tou= ch > the module system. The expander gets rid of them in the same way it > gets rid of let-syntax; expanded code doesn=E2=80=99t need to care about = them > any more. > > Implementing this means changing the expander=E2=80=99s idea of a wrap so= that > it contains property bindings, much as has been done in Chez=E2=80=99s ve= rsion > of psyntax: > > This is a non-obtrusive change entirely localized to the expander as > it exists in a live Guile system. I don=E2=80=99t see any major issues he= re or > have any questions. > > When we get to module-level property bindings, things get trickier. > I=E2=80=99d like a bit of guidance here. First, to clarify the SRFI: > identifier properties, as the name suggests, are attached to > identifiers in the sense of define/import/export. If you import an > identifier from module A which the unrelated module B has attached a > property to, you won=E2=80=99t see that property =E2=80=93 unless you *al= so* re-import > the same identifier from module B. Identifiers are organized, though, > by keys, which themselves look like identifiers but those identifiers > are actually used only for their bindings in the sanse of > =E2=80=98free-identifier=3D?=E2=80=99. (Keys have to be defined =E2=80=93= the fallback to > symbolic comparison doesn=E2=80=99t apply here.) > > To support this I will have to extend the definition of a module in > boot-9.scm to add, effectively, a second obarray =E2=80=93 this one mappi= ng > variables to mappings of bindings to property values, rather than > variables to values directly. However, it looks to me like there is > some duplicate definition between C and Scheme here, and I would also > need to update libguile/modules.c to at least be aware of the new > structure, and probably write the property mapping code in C there as > well to make it work as I describe below. Is this a correct > assumption? > > Looking at how syntax transformers work in the current code, the > =E2=80=98define-property=E2=80=99 form will probably have to be considere= d primitive > down to a fairly low level. As I understand it from looking at > expansion and disassembly, (define-syntax x y) first expands into > (define x (make-syntax-transformer something something y)), then on > the way from Tree-IL to bytecode it becomes an intrinsic call which is > effectively (define! (current-module) 'x) followed by a (set! 'x > (make-syntax-transformer something something y)). It looks like there > might be double definition here too: once in a direct route from > Tree-IL to bytecode, another with the same source and target but via > CPS. > > In any case, based on this, I will add a > Tree-IL node which compiles to a new define-property! intrinsic the > same way compiles to a define!. That primitive will > add the var -> binding -> value mapping to the module. Since there is > no set! operation on properties, I think everything can be done in one > intrinsic. One minor question I will have to solve is how to represent > the binding used for the key down at this level. I am sure there is a > simple answer to this =E2=80=93 possibly just a pair: > ( . ) > > There is an alternative approach which looks easier, which would be to > have define-property at the top level expand directly into a call to a > new =E2=80=98module-define-property!=E2=80=99 procedure. But I assume the= re is a > reason macro transformers and other definitions were done the way they > are done =E2=80=A6 > > Also, because this reaches so far down into the internals of Guile, I > assume it will be necessary to adapt some of this specially for Hoot > as well. I haven=E2=80=99t looked at the Hoot sources yet =E2=80=93 it mi= ght be an > idea to wait until Andy Wingo has finished porting psyntax to Hoot > before trying anything there. > > In any case, there is then one last step, which is to add code > adding/merging properties when modules are imported into other > modules. This should be a fairly simple hash table/alist/whatever > union operation, but I haven=E2=80=99t looked into it yet. > > Since this does touch nearly every level of Guile=E2=80=99s compiler, I w= ould > appreciate some feedback and ideally the opportunity to consult > occasionally while I=E2=80=99m working with someone who is more familiar = with > all of this code than I am. > > Many thanks in advance, > > -- > dpk (Daphne Preston-Kendal) =C2=B7=C2=B7 12103 Berlin, Germany =C2=B7=C2= =B7 http://dpk.io/ > One Thing to name them all, One Thing to define them, > One Thing to place them in environments and bind them, > In the Lambda Order they are all first class. =E2=80=94 R= 2RS > >