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: Some improvements for cl-flet Date: Sat, 11 Sep 2021 12:51:28 +0000 Message-ID: <87bl4zqnqn.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="38119"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Stefan Monnier To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Sep 11 15:04:37 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 1mP2gO-0009h3-7c for ged-emacs-devel@m.gmane-mx.org; Sat, 11 Sep 2021 15:04:36 +0200 Original-Received: from localhost ([::1]:37252 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mP2gN-0000B7-AW for ged-emacs-devel@m.gmane-mx.org; Sat, 11 Sep 2021 09:04:35 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55332) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mP2em-00067t-V1 for emacs-devel@gnu.org; Sat, 11 Sep 2021 09:02:56 -0400 Original-Received: from mail-wr1-x429.google.com ([2a00:1450:4864:20::429]:46711) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mP2el-0003bA-11 for emacs-devel@gnu.org; Sat, 11 Sep 2021 09:02:56 -0400 Original-Received: by mail-wr1-x429.google.com with SMTP id x6so6755266wrv.13 for ; Sat, 11 Sep 2021 06:02:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:message-id:mime-version; bh=X7Og2K7Ud4OUB0THirJUTy49m/Icldx64P2RJySBu1o=; b=bAQJR8kPMPGWmEMmzsFx/9FJVFTnWjC5OBuWzwide3SSx+NoA5FE9XK3mQ4BY9zXHR fiR+YsbwZuMA9XlUpO4HyH6jmFKuINUMLAexDaFWNxAHt6/+JUa86RT74jZ6ZboSeUMA MT9HjptyOSLWwyG+D+TrlcYDrqUkFFQK1geXQ6jX7MxFm8v+FGAPIZxrY8T8ozAk3LzZ 0AorH7++zfQ0mo2m/W8occHu+kSCiS8vxeZiBqIxVKReansVwjmjAva6pVvzdN339wmd vWWdZgAaB2Qt5Zx472IHu0nn22vz3ZvQ1gZSnak9t9l9rxbGWjnOrVLYz+GWgIrP0Qhl igXQ== 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:date:message-id:mime-version; bh=X7Og2K7Ud4OUB0THirJUTy49m/Icldx64P2RJySBu1o=; b=kZmDPglMDwCKXaDJQVtdONsYXjQC/QkxbJKVZimEPzsCDahdUyI+eiipJ/CoicjWQS dWd4doHc26oVLJ2VR8Umgi+Uy4bhprJiXH1w7Hc0N0Zf1kF0o2+q9LywDOe5YlfCXkzj phqCg4f5w1xPqB5D3dRott/BOTajKzPxZJGCAUI0VfILGSZdYlQGsaS6nyBympeKThiX is4yOQ2BQ8r6tZPQmjv1ftk35vlofYHN9L1gf9+dbi5V9uw0/XrUpO5jXIQv0mDvoOre 1cThEomlLDyrqKQnwdiQU4r6XhNiQxg+2hZ4PwT4A9VIotQPbuJvIMPutLoembvuAj0N 0dLA== X-Gm-Message-State: AOAM532YaU/Hu4go6mrfxJCC+BW8kAExPcTm4l+wNqAxF+ZqC8qFR9bf AHfwje+CMnBwEwemTjzVuUs2M0SioJg= X-Google-Smtp-Source: ABdhPJxZhcm86ZahNLsbKkayZDK9OFdFO5fMcKIpekHevlcl81fFAAAkQX4w6iIaAOtXIsWAjZZacQ== X-Received: by 2002:adf:df0d:: with SMTP id y13mr3039290wrl.335.1631365372366; Sat, 11 Sep 2021 06:02:52 -0700 (PDT) Original-Received: from localhost ([185.220.102.240]) by smtp.googlemail.com with ESMTPSA id h11sm1995049wrx.9.2021.09.11.06.02.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 11 Sep 2021 06:02:51 -0700 (PDT) Received-SPF: pass client-ip=2a00:1450:4864:20::429; envelope-from=nuclearspace@gmail.com; helo=mail-wr1-x429.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham 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:274547 Archived-At: --=-=-= Content-Type: text/plain I've implemented some fixes for ~cl-flet~ necessary to address an issue with ~cl-generic~ but also improving ~cl-flet~ proper. Before I post the patch, I'd like to clarify one issue. ~cl-flet~'s ~(func exp)~ syntax, as described and implemented, is incompatible with ~flet~ syntax as specified in Common Lisp. Namely, ~(func exp)~ syntax does not allow to distinguish between a form ~exp~ returning a function and an arglist ~exp~ for a function ~func~ that always returns ~nil~. Consider the following valid (but stylistically poor) Common Lisp code: #+begin_src lisp :wrap example lisp (flet ((f #'g)) (f t t)) #+end_src #+RESULTS: #+begin_example lisp NIL #+end_example If I understand the purpose of ~cl-lib~ correctly, corresponding ~cl-flet~ form should return ~nil~ as well. However, it errors: #+begin_src emacs-lisp :results code :wrap example emacs-lisp (condition-case err (cl-flet ((f #'g)) (f t t)) (t err)) #+end_src #+RESULTS: #+begin_example emacs-lisp (void-function g) #+end_example In case it's not clear what's going on: the previous example is equivalent to the following one, only with ~function~, ~g~ replaced with ~x~, ~y~ correspondingly: #+begin_src lisp :wrap example lisp (flet ((f (x y))) (f t t)) #+end_src #+RESULTS: #+begin_example lisp NIL #+end_example but due to ~(func exp)~ syntax, ~(x y)~ is presumed to be a form meant to return a function, rather than an arglist, and so #+begin_src emacs-lisp :results code :wrap example emacs-lisp (condition-case err (cl-flet ((f (x y))) (f t t)) (t err)) #+end_src #+RESULTS: #+begin_example emacs-lisp (void-function x) #+end_example The syntax of ~flet~ could only be compatible with ~cl-flet~'s ~(func exp)~ syntax when ~exp~ is presumed to be a non-list. For example, ~exp~ could be a symbol. The following expression could also be unambiguously interpreted in style of ~(func exp)~ because ~nil~ is not a valid function argument: #+begin_src emacs-lisp :results code :wrap example emacs-lisp (cl-flet ((f (lambda nil nil))) (f)) #+end_src #+RESULTS: #+begin_example emacs-lisp nil #+end_example However I don't think it's worth it to use complicated rules to distinguish such cases. ~flet~ just has its own syntax, incompatible with the (Scheme-inspired, likely) idea of binding a function to a variable. Such complications would keep ~cl-flet~ unfit for use in macroexpanded (and otherwise generated) code. Last but not least, ~(flet ((f (lambda nil nil))) (f))~, etc., is not a valid Common Lisp code. Note also that the following is valid (and stylistically fine) Common Lisp code: #+begin_src lisp :wrap example lisp (flet ((f ())) (f)) #+end_src #+RESULTS: #+begin_example lisp NIL #+end_example However, evaluating corresponding ~cl-flet~ form errors: #+begin_src emacs-lisp :results code :wrap example emacs-lisp (condition-case err (cl-flet ((f ())) (f)) (t err)) #+end_src #+RESULTS: #+begin_example emacs-lisp (void-function nil) #+end_example Finally, note that (an equivalent) ~(func exp)~ syntax could not be adopted by at all by ~cl-macrolet~, as macrolet forms support destructuring lambda lists. For example, the following is a valid (but stylistically poor) Common Lisp code: #+begin_src lisp :wrap example lisp (macrolet ((f (lambda () 'x))) (f t nil (t t))) #+end_src #+RESULTS: #+begin_example lisp NIL #+end_example Given all this, I think ~(func exp)~ should be dropped from ~cl-flet~. My patch (already discussed with Stefan Monnier to some extent) introduces function ~cl--expand-flet~ which retains the functionality currently provided by ~(func exp)~, in an unambiguous way. I suggest to move it there, away from ~cl-flet~. Do you agree? --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJLBAEBCgA1FiEEgu5SJRdnQOF34djNsr6xYbHsf0QFAmE8plAXHG51Y2xlYXJz cGFjZUBnbWFpbC5jb20ACgkQsr6xYbHsf0QOqA//UMEp7EVGZTJvIrMhJ2+2T2P5 gQTeD9gPx2eilKSlBQ2cs+smtH48kZd+3pUVyzCNr9zhcXuqnTPOi11J56+k3CO/ iGAcfKZRpEOXK3IERPjiwChSmUgBpdhqKC2PkNnI0dL2oFZSXiP2tJ5NZoqaQYgX 9EPAkei4GIUtKazsH7BwJGwY7ExfMksGS1jmfmsS8VIm7nGTvjWXn61D0oBTldpi rmtbjqcQWHWSkBhXqKtmYM/SBcMdbgaAobZsk6njpO1sUU+7/IN4wdmT8kDJ2Ayl K0O4ZFBbwCLpccYfeS/UKUE7+kCaQlpfoKnyiHgs5PtAHH2ZLiualrE7kYEY2F+e udG8KS39nNV8yOeevtSLtuzLgaa5rFS8EhWZuvfjolOpmnRCm+5chLVYPDgvy8wO /qnx4ihTzU1t+497VTPWY7v6t5T6a8Xg9PUEUZzAq9pp5vpbCpkTCurvJQa7drrN xPCg4mgXuuFzeVS5cGS/WY46GV7whqd+o1PijhxQXVgIPUIced97PmwapvyWVg/f kXg4JGxW90yWC1INIEdAIbv6PXNc9gJ4vxGLohTFlvfjDCiQLqOL+q5BBXVfvAwd JNmHBRGTsr3JzI8TIcBXtsM85Q+KBA/XQwIBa9VvcJ6xZRhJ6l5UIRXiNXxdRy3v hFj/EKZpMne8GixH1sY= =M6II -----END PGP SIGNATURE----- --=-=-=--