From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Daphne Preston-Kendal Newsgroups: gmane.lisp.guile.devel Subject: Proposal: Identifier properties for Guile Date: Tue, 10 Sep 2024 22:09:02 +0200 Message-ID: <05A7E253-3DFB-4CA8-A257-353BD5FB650F@nonceword.org> Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51\)) 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="33924"; mail-complaints-to="usenet@ciao.gmane.io" To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Tue Sep 10 23:08:42 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 1so86L-0008e5-4Z for guile-devel@m.gmane-mx.org; Tue, 10 Sep 2024 23:08:42 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1so85x-0003gZ-A7; Tue, 10 Sep 2024 17:08:17 -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 1so7Au-0007aO-BS for guile-devel@gnu.org; Tue, 10 Sep 2024 16:09:20 -0400 Original-Received: from fout2-smtp.messagingengine.com ([103.168.172.145]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1so7Ar-0003SU-Sy for guile-devel@gnu.org; Tue, 10 Sep 2024 16:09:20 -0400 Original-Received: from phl-compute-07.internal (phl-compute-07.phl.internal [10.202.2.47]) by mailfout.phl.internal (Postfix) with ESMTP id 50F9213801F0 for ; Tue, 10 Sep 2024 16:09:15 -0400 (EDT) Original-Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-07.internal (MEProxy); Tue, 10 Sep 2024 16:09:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nonceword.org; h=cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:message-id:mime-version:reply-to :subject:subject:to:to; s=fm1; t=1725998955; x=1726085355; bh=qd 7knniJKLCiTG6A4pFZmUfZfR1YDuTM6wIa/lIuqxg=; b=FZ4psqlCu1xrAb43FM TWGwuMurRGtv748EsXNtjuB5ZPrJbbgdUlR0OAzF5ERA3AjDBW9Qtpu1r+mtlTlu /rCNegFbalt+tdoPfgeW5+Fw6WciVg5cuqOB5lRa1N1GxqlNEh/AeW9DrPMkq8Hi Hwg9mpIIti66DJUg41Qyjc+dBjn5IXpzpUPPk+bb5E0dAVYJSLr8kDPsXZHyI2zk SKcIW6rGDSL03HqUh1NKJGGkVwMJfozVKu9Qjs+nGVB0u0/FlpvGmhVG6tGFgRtn T6SxpFTigu4OXy0U2p6cjYJrSp6x/jMs9q0njB4aiKxWeKpJXYhN/2XeUWWJBUyC V9Dg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:message-id:mime-version:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1725998955; x=1726085355; bh=qd7knniJKLCiTG6A4pFZmUfZfR1Y DuTM6wIa/lIuqxg=; b=enOiiVvUOGC4u5gWp6uFuS1ujwees0sUvUkmozkN4Jdr gJDzwETdQtMRbdDjjKYp8BuE+ufZFuRLdE6AhygHxpfPGFvunxv4bPy7asVkkItQ qqTCPmqKBi6RxXw3iE5Lmkuc3aSM1sc60U7pdkt9D2erQQyLe4CmggR2jJx/xXBj SLwkc86GErtMfly5EyikFscQajRQg2EvBq5OUEi9iM0rnLFCYB8nlhI219Thi+nj XQ8/u7wLusI1EAcNc4sT67KrffwZGR0kT6dtNjfOj+S5svVb4yrhF87bQcD6OtXJ B4GyTbEPh2FYWJmPYGNTT27vnE2aohmw9fePV112nA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrudeiledgudefiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecunecujfgurhephfgtgf gguffkfffvofesthhqmhdthhdtjeenucfhrhhomhepffgrphhhnhgvucfrrhgvshhtohhn qdfmvghnuggrlhcuoeguphhksehnohhntggvfihorhgurdhorhhgqeenucggtffrrghtth gvrhhnpeeiheeuveevtdekhedugfejgffgtdeguedtleffteefhedugeehvdeffeevtddv vdenucffohhmrghinhepshgthhgvmhgvrhhsrdhorhhgpdgtohguvggsvghrghdrohhrgh dpghhithhhuhgsrdgtohhmpdhshihnthgrgidrshhspdguphhkrdhiohenucevlhhushht vghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpeguphhksehnohhntggvfi horhgurdhorhhgpdhnsggprhgtphhtthhopedupdhmohguvgepshhmthhpohhuthdprhgt phhtthhopehguhhilhgvqdguvghvvghlsehgnhhurdhorhhg X-ME-Proxy: Feedback-ID: ibc314252:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Tue, 10 Sep 2024 16:09:14 -0400 (EDT) X-Mailer: Apple Mail (2.3776.700.51) Received-SPF: pass client-ip=103.168.172.145; envelope-from=dpk@nonceword.org; helo=fout2-smtp.messagingengine.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Tue, 10 Sep 2024 17:08:15 -0400 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:22680 Archived-At: Hi! I want to implement identifier properties a la SRFI 213 in Guile=E2=80=99s= 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 = the best things since sliced bread. I=E2=80=99ve gathered some example use = cases 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 = an 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 = touch 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 = version 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 = here 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 = *also* 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 = mapping 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 = considered 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 = there 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 = might 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 = would 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, --=20 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 = R2RS