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: Sat, 09 Oct 2021 05:33:00 +0000 Message-ID: <874k9qdapf.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="7570"; 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 Sat Oct 09 07:45:35 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 1mZ5As-0001jt-JT for ged-emacs-devel@m.gmane-mx.org; Sat, 09 Oct 2021 07:45:34 +0200 Original-Received: from localhost ([::1]:38634 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mZ5Aq-0004tD-VW for ged-emacs-devel@m.gmane-mx.org; Sat, 09 Oct 2021 01:45:32 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33112) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mZ5A4-0004DE-Fk for emacs-devel@gnu.org; Sat, 09 Oct 2021 01:44:44 -0400 Original-Received: from mail-wr1-x433.google.com ([2a00:1450:4864:20::433]:42975) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mZ5A2-0008Tw-OJ for emacs-devel@gnu.org; Sat, 09 Oct 2021 01:44:44 -0400 Original-Received: by mail-wr1-x433.google.com with SMTP id v17so35967716wrv.9 for ; Fri, 08 Oct 2021 22:44:42 -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=KdC56o/lJAmGzotadSqU7mchwbGrzSOaYjlUQs4diBM=; b=TPu5EHG18E36xTJur5eQlRTigOVc3anqNgQmk1d5zNRV7bQn9wXdFel1DNZ3RybFhK PTsLDW7jtB8Z9EcDKLoH3UmeU82JRY3ZMjVP4ofL3nJg30CKHqIopxIrkCOndTbdXHQB eoOzS6i4Gpai0Tm8GtcJsenZ6wbmgFXaxVLBB4myu7i1nezzaQR3521D0ZQCJQb8Vx0H 2uY7FBypdQTondKgBrWer0ANtZWHcM8XprnjZ44Yg1FyfUmcYetLmbP8AmeOuH6f003L EBG6YanvGO3utM77BpL20h4LMwziacTAetlGklLLHR14qOiFFSmhxYusVp5K8wcMO+Ps kbZw== 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=KdC56o/lJAmGzotadSqU7mchwbGrzSOaYjlUQs4diBM=; b=hTkn57kAl+A6llWYBT0u20yVdk3vENJlpd3QCDrfzEGAA7FuOVZp/KO885fF47kmJy W+1onhhnkKibDraWMynyV0V6ZkybQbLNDKwONzFVHAGPfBvj5BBj6mZHuXOZU3LrgRUg Jv4JWA9WoityAwO3Se3hiXqDHLdk6IB5wBWTEt/oR1lt6do2q8j2oN3DS03k6KOxPVtc iR01HXmablKwXDCsil2Y/goqw2A5pH4Nq/DL6UIegy3KxMBdW8JQT6yWN14Z3z3x1F8X P74ij0uSHGWNKkvRICdGyDXNzZY5rqy0iK5QTIdCLUgP3jSqsk/DQJYAt78DKZENf+YY V0Eg== X-Gm-Message-State: AOAM533CDdrIvlO/p6r2D7npA8fiMN9NE5uVVuZzlyNzA3uhzLqP6nuY suobU8wbbJhNFt9d1Cf7FWU= X-Google-Smtp-Source: ABdhPJxql+8dtCGbr2eLeuRPuJsx6HD2lzmDIMXEwvwpWmID5Ux9uzz6nxtTUTLdhKLmfyeHZHyiZA== X-Received: by 2002:adf:9c02:: with SMTP id f2mr9123762wrc.329.1633758281100; Fri, 08 Oct 2021 22:44:41 -0700 (PDT) Original-Received: from localhost ([185.220.102.246]) by smtp.googlemail.com with ESMTPSA id e8sm1567792wrg.48.2021.10.08.22.44.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 Oct 2021 22:44:40 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2a00:1450:4864:20::433; envelope-from=nuclearspace@gmail.com; helo=mail-wr1-x433.google.com X-Spam_score_int: 26 X-Spam_score: 2.6 X-Spam_bar: ++ X-Spam_report: (2.6 / 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, RCVD_IN_SBL_CSS=3.335, 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:276587 Archived-At: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Stefan Monnier writes: >> +The return value of said lambdas should be either >> + >> +- a valid let-binding (SYMBOL function) to be used in let* >> + bindings over BODY so that SYMBOL could be used in place of the >> + corresponding function name in BODY >> + >> +or >> + >> +- a list (NIL EXPR) for EXPR to be used in BODY in place of the >> + corresponding function name as is. > > Can we simplify this so only one of the two is supported? There are several ways to simplify this. Here they go, in the order of attractiveness (to you, as I perceive it): a. When flet-expander returns a symbol, plug it in as is. If it returns anything else, use it as initial value in a let binding. This basically mimics the present mechanism. It sounds good but the questi= on is, why are we certain that we'll only ever want to plug in symbols. Plugging in symbols and symbols only is arbitrary, as my example with symbol-macrolet demonstrates. Aren't values of type =E2=80=9Ccompiled-func= tion=E2=80=9D worth injecting directly as well? Arguably more so since at least they won't evaluate indefinite number of times with possible side effects. Same appli= es to other constant values that include present or future funcallable objects. What if expander returns nil or t? We probably should add exception concer= ning those. Overall, such spec involves guessing and eventually will get more complicat= ed than what we started with. Which is why I don't recommend a. b. Allow building more let bindings than necessary As long as we have to distinguish between buliding a let binding and pluggi= ng in an external form as is, our lambda must return values of two distinguish= able types. We might however unconditionally generate let bindings and use retu= rn values of flet-expanders as corresponding initial values. As was the case = with =E2=80=9Ca=E2=80=9D, the values don't have to specify gensyms then, and can= be used directly instead. Note however that this would introduce incompatibility with the existing code due to presence of (func exp) syntax in cl-flet: it might be = that some code that used to evaluate several times at runtime will only evaluate once. I understand that this is deemed unlikely (and I wish this logic cou= ld be applied to make consp return its argument for true --- even though this would not be not CL-compatible). Good news is, this would also make cl-flet with (func exp) more predictable. So far low-level functions of Emacs that generate Elisp code do try to avoid building more let bindings than necessary. In fact, cl-flet itself does th= is right now. IIUC, with native compiler in action, we might not care that mu= ch about minimizing let bindings. However, cleaner code generation helps with debugging, and not only debugging macros. My impression is, lispers generaly don't produce cleaner macroexpanded code because it would take too much time to write a procedure that does and beca= use they don't see that much value in clean macroexpansions. I think they are valuable enough (which is why I took the time to ensure it in the case as important as cl-flet). Also, despite the fact that clean macroexpansions a= re not fashionable, complaints about difficulty of debugging macros themselves= or of macroexpanded code, are fairly popular. Cluttered macroexpansions contribute to that difficulty. So I don't recommend b either. c. Transfer the relevant information from return type of code-generating lambdas into arguments' types of expand-flet c.1 We could introduce another argument that explicitly lists the symbols = for which forms returned by flet-expanders are plugged in and no let bindings a= re generated. c.2 The expanders could be specified as either lambdas, in which case the return value is used in the flet body as is, or, say, singleton vectors [lambda] in which case the return value of funcall of the 0th element is us= ed as let-binding. Downsides: (c.2.1) it might be worth it to make this decis= ion late rather than early; (c.2.2) the interface gets more complicated and less reasonable. In c.2 I picked vector because it makes it less likely to confuse lambda expressions with something that should not be evaluated but overall I think complicating expand-flet is a bad idea anyway. So I don't recommend c as w= ell. The proposed return value types, (var value) and (nil value), looked more straightforward to me than alternatives I could think of. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJLBAEBCgA1FiEEgu5SJRdnQOF34djNsr6xYbHsf0QFAmFhKYwXHG51Y2xlYXJz cGFjZUBnbWFpbC5jb20ACgkQsr6xYbHsf0S1tg//WYRVfztGWN9k1Il6KlfMFcPs w2DElNOaRiHIZKnbd//C9Tp7K3ypvB4nNhiSdkxrSfERJc9SnXX05h80RSIAMgB/ r9UITgu7cZqP5b2b4LmfxLXpkgGgvpIYYXCk/uHFP5MujKU0V0PN1Ywf7ehE0DYQ C9X1Q2SLSufU6uSqvFH5H0V88XLqQ8jr/8zw+BJzxDoWbJBoaHkH5oh6mbcoZnBs /ItnECmEW82mZ+VH+SSo+csX2F+dSRmubEBnSjUnkiqWizRfBnIsYuUCi0uRHC5J IuaZXgnHlpVBd9H5g08W7UjsddtfhwP76k6SOJVykXAUpLXV+2NrwcObX892D6lV xWLWykK4Fbm5MwzT83OSy1qhWJSX3KoM7x72X91M87wGjFvNCVsrHpDRo8l1p9KG eq+Pr0mugOh2h5jmCimEbenYOjh4Frg7o1UbUESWTjRlF0GTMIcBRINxD6XD0+bn Awq1NlR9flf9Uwjj3W1EIlHt2wDfe/FGVBgx5KBxAfhgZA51/TB6/Tl1ExrFt0j8 E5OAfjuTXyQCPLh0YY6QtDoSi+ec+avAjZ2tErbpjXbSa/oC+5eXuEZoRPZwPBVH x2hEoJCgaDMRIJzLSh92QsMVfhmEkDG7DqUE+XP/xx+ItWOVSRS9e46RYoH2g5Kx 4+2bLTw56xh1LIIVGoo= =S0jX -----END PGP SIGNATURE----- --=-=-=--