From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: akater Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Some improvements for cl-flet Date: Thu, 07 Oct 2021 05:02:23 +0000 Message-ID: <87pmshqvfk.fsf@gmail.com> References: <87bl4zqnqn.fsf@gmail.com> <87mto2gbpu.fsf@gmail.com> <87k0j6gbjg.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15867"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Oct 07 07:14:50 2021 Return-path: Envelope-to: ged-emacs-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 1mYLk1-0003wP-Pw for ged-emacs-devel@m.gmane-mx.org; Thu, 07 Oct 2021 07:14:49 +0200 Original-Received: from localhost ([::1]:50256 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mYLk0-0000HS-5J for ged-emacs-devel@m.gmane-mx.org; Thu, 07 Oct 2021 01:14:48 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48256) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mYLjE-00082F-LJ for emacs-devel@gnu.org; Thu, 07 Oct 2021 01:14:00 -0400 Original-Received: from mail-ed1-x531.google.com ([2a00:1450:4864:20::531]:46004) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mYLjC-000053-SP for emacs-devel@gnu.org; Thu, 07 Oct 2021 01:14:00 -0400 Original-Received: by mail-ed1-x531.google.com with SMTP id r18so18283801edv.12 for ; Wed, 06 Oct 2021 22:13:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=FVRI4okAtIMuL+hvlbtCwcNFMEUzlE09SZTJlPxYcgM=; b=iVa3iENxqRzF18ShJBuUCG5emBAtbupGUMRIhgkO3Bu32SO6eqPofc2HsggnRgTMxA 3tnXRQbGffaQxXJiIVmqBC455wZlUHNZq0JjNvw0NJjnNeNvBZeBQr8zhdBiYt0H4q0d zRa/TZYfQQ0/lJmcpN51VeVYmdVJEItyNYOle24yCfAPVrVeLMNXlvJ2UOGtRKMi9UCl v9dUANHHaPdq0c1hPpsCwmEkGr8StWnxKnSaEbgjQuZZ2/sZYlLotj4hTQlUtpmZ+nk7 UpqUJQulpfLhPfs1RjmPwJ9XFhmXU/82AI0vpJjoJ+E++xVHwWaR7in0NH4wyKM6aLZY h49w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=FVRI4okAtIMuL+hvlbtCwcNFMEUzlE09SZTJlPxYcgM=; b=dblv+fG1PAPUyin1g6zksfxkcibBes8w5kSLoia24F6wsj+bOd4UogFsrx3SKEtaeY IfBKeIEyb0yLUY6c4zR+7oDCk08yuihbbL9hWDzICazatZ+NrFA89b+5ZSMBzdNne6bI spNn6fzrr5jFEGxB3/sov40Bo5TazfnbfpbSZC1sO0ZSxk+jCZO3ArgITqYR4PPTfcSY 96b1BFslCMPPEdowJw4sPEX85+UdCKa/ZHLL/beWkNSPAAgPk+Gk1KcAwEcx+l+4ekhi 6uF56J04hVIDPuGLlIKPgV6tcfr5E6HpSG4c0sHdIeJ5uk2pnrjy1SVlCWLQnuVmBR8Q Ud9g== X-Gm-Message-State: AOAM530L31c2V6yWw166Xft6JhE+eJOUVBNRNsj/fnKCyN8BwqbkP8p1 0Lf/2XNzlL5pUn4rjjF85c+dMLA9BJVHOeav X-Google-Smtp-Source: ABdhPJwUo2W+5TiVcHT0MjvLCOK8IBN2dwJsTKkCnE0nqGvKGRCxzHaSsm9W4mZXJqqvOPd70RD4cA== X-Received: by 2002:a17:906:6691:: with SMTP id z17mr3066472ejo.207.1633583636222; Wed, 06 Oct 2021 22:13:56 -0700 (PDT) Original-Received: from localhost (tor-exit-48.for-privacy.net. [185.220.101.48]) by smtp.googlemail.com with ESMTPSA id q11sm10911037edv.80.2021.10.06.22.13.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Oct 2021 22:13:55 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2a00:1450:4864:20::531; envelope-from=nuclearspace@gmail.com; helo=mail-ed1-x531.google.com X-Spam_score_int: -7 X-Spam_score: -0.8 X-Spam_bar: / X-Spam_report: (-0.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, FREEMAIL_FROM=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:276476 Archived-At: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Stefan Monnier writes: > Maybe it might be worthwhile splitting it into 2 or 3 patches so as to > better see how we got to the level of complexity. > See more comments below. Local setfs certainly can be added later (or simply dropped, until better times). It will simplify the patch. > Why do we have/need this? Does it work with other things that use > gv-places, like `push`, `pop`, `cl-callf`, ...? If so, how? > If not, then we need another approach which does. I added support for local setfs mostly =2D because I decided to implement all features of flet since I'm dealing with low levels of cl-flet anyway and this might be the last time it happens; =2D and since ignoring local setfs now might make it harder to implement them in future. This functionality does not have any more to do with places than (cl-defmethod (setf ..) ..) so I guess it has no relation to gv-places, right? > > I thought handling `cl-flet` of (setf foo) would amount to calling > `gv-setter` to get the symbol corresponding to `(setf foo)` and then > c-flet-binding that symbol instead of `(setf foo). > At the very least, gv-setter will fail for local (setf car) and so on. I don't know how cl-flet should treat such things (in Common Lisp it's UB) but I saw that cl-flet performs local redefinition of car just fine so I followed suit. >> +(defun cl--expand-flet (env body &rest flet-expanders-plist) >> + "Return a form equivalent to `(cl-flet ,bindings BODY) >> +where bindings correspond to FLET-EXPANDERS-PLIST as described below. >> + >> +ENV should be macroexpansion environment >> +to be augmented with some definitions from FLET-EXPANDERS-PLIST >> +to then expand forms in BODY with. >> + >> +FLET-EXPANDERS-PLIST should be a plist >> +where keys are function names >> +and values are 0-argument lambdas >> +to be called if the corresponding function name is encountered >> +in BODY and then only (that is, at most once). > > Why "at most once"? We don't want to end up calling different functions in different instances of local function calls which share the same name within a single cl-flet form, for whatever unforseeable reason this might happen (like poorly written flet-expander or poorly written exp in (func exp)). The best way to ensure local definitions are consistent is to only produce the local function once per local function used in the body. If the local function is not encountered in the body at all, the corresponding function object (or whatever exp in (func exp) evaluated to) is never produced. Hence, =E2=80=9Cat most once=E2=80=9D. Note also that in the use case this patch was motivated by, we only need to evaluate arbitrary code once per encountered symbol: (cl--expand-flet macroenv (cdr parsed-body) 'cl-call-next-method (lambda () (push cnm uses-cnm) (list nil cnm)) 'cl-next-method-p (lambda () (push nmp uses-cnm) (list nil nmp))) > Can we simplify this so only one of the two is supported? Maybe but before I reply properly, I'd like to know if you have any thoughts on https://lists.gnu.org/archive/html/emacs-devel/2021-10/msg00522.html (it is relevant). --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJLBAEBCgA1FiEEgu5SJRdnQOF34djNsr6xYbHsf0QFAmFef18XHG51Y2xlYXJz cGFjZUBnbWFpbC5jb20ACgkQsr6xYbHsf0SWbw//aihdtvSduF/7HTP0N5Xga2Is +F8X9hOgpyY8nQzY/NvSbyZYcjvMQd87/VzYYGY7Nt7BMdZO9gvzpf2BNgNRYkJG rrR2OCltdlQCpIhWher5R9fSpj2+vNn7GvoUu1Okd+CxowF4dGpD6ijEcFB9Ey/6 iiaYD+i5MFqg6zFlzUnk8D/8+Lp3s9OleL5gXvugbrtL/3IhZCJvpBDannpVpm0K soMfajof1HktyHWzpJMI5MeY5jJoKR8jNiG+ItbLs81W+7xFW3LfJ6dv7znvKbR1 evwAYhjGYshZJv9/qFtzrj7mYdHt2ppz+fowiQSsJABXX5uDRwkUfI3/5Jo6/k+D KQ9tmEfsHay+ac/Aqcz7hVMLw2b1nDN8JxwV1THG6uekSf5I+9waz0codUH3mcY8 uxz4sYyWXpo6VFA2McRBsQjEg/1CnUrf5X7WzP/LpvtbjJnjVYCHad4uWzo+JxH6 A3wBlVZnjiYiRDmFRCv7oTm+F8l5wePb5IxPGRDyEXWZaBCqy3Le1i+LMJATYHcQ WoWOK7UCJEEjrCAXlejd74BuBLyllr7JaFpJLSkUSHRAuI2jSmmivBcyYh1BoKoj IrDQhgyWfCal/9Hfyv7OmxhGp67nwROBnzOQ/I/oS/WqpmqwJrAOD3cGqbOF2omA XsG4H2eRpl5DuT8Kisg= =YYhH -----END PGP SIGNATURE----- --=-=-=--