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: Some improvements for cl-flet Date: Sun, 12 Sep 2021 03:35:12 +0000 Message-ID: <874kaqqxe7.fsf@gmail.com> References: <87bl4zqnqn.fsf@gmail.com> <87czpe4rj2.fsf@web.de> 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="30684"; mail-complaints-to="usenet@ciao.gmane.io" To: Michael Heerdegen , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Sep 12 05:47:43 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 1mPGT1-0007ml-BX for ged-emacs-devel@m.gmane-mx.org; Sun, 12 Sep 2021 05:47:43 +0200 Original-Received: from localhost ([::1]:49584 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mPGSz-0000cG-Mj for ged-emacs-devel@m.gmane-mx.org; Sat, 11 Sep 2021 23:47:41 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41700) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mPGS1-0008MT-R7 for emacs-devel@gnu.org; Sat, 11 Sep 2021 23:46:41 -0400 Original-Received: from mail-wr1-x42a.google.com ([2a00:1450:4864:20::42a]:36601) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mPGS0-0008GO-66 for emacs-devel@gnu.org; Sat, 11 Sep 2021 23:46:41 -0400 Original-Received: by mail-wr1-x42a.google.com with SMTP id g16so8949948wrb.3 for ; Sat, 11 Sep 2021 20:46:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:subject:in-reply-to:references:date:message-id:mime-version; bh=9iGIRiQuXbZE8SWeWbefkLs3po6yE3Z8mdYmuH0HHqQ=; b=lqFNK07Qa9B7QpXg50iyYVNgvO9PQgWCRX9dQa62sJkFjOtLh0gUv93dnOi/3NOrvB RjPyx5JHMl4Umjj8zOhkSqnSPFlBLcGpNUaTcZtIoDdhfCINTgGX29wuqQMjFPv20ZGT B15XpqoQS5GX3AkR2Y41jto8z+CzDQskcWLwfZLfOgE0Mz+LUrKJl3jHtiww1kWH6rmg yo0KEZpQAjkS3YMl578Jpr5WB34vlTPHDeY7PgITbIHmEHTf04jRvyiRrGoELhHKnZ36 XAgTxVBDD3Am+ItmCxJE50xVKrL1FOE/pgQeJ5s9ormah+tuQvDSdF/g5mPR0lgwxTg+ 35ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:subject:in-reply-to:references:date :message-id:mime-version; bh=9iGIRiQuXbZE8SWeWbefkLs3po6yE3Z8mdYmuH0HHqQ=; b=lY8H296VtV+4GSqyJuAJp9Bw3v9cpz3bJeiJYM+51z+Fm48SY46xyc6maC30xvXkXw zFqKT2i3YK63gK0Z7Wfsk0qTlOIQkyZ2/UgZaEzukunthv2zYm0nMTRSCSwGI8MaZ04P xDVMw8ivQh3XdR9WWu6RfEKljF6WJ6DB6NbKu9EOLmGvtOLY65E9GXUzGJcbECEg3L4U uf1F3EvhZ8pNpEOxDBhimYZL3l6wNgd5UQb4MOIjGRX+oM1hu70it//YrogTT41BTn3E MQBOHX6DdN9Ak1mP67jEiePSGQxQArNUuLhk9wSiFivzVz4ZxVPhnYENUZdVHUuIXKkH DudA== X-Gm-Message-State: AOAM531zphQ/1Mv1EocFYtjL1ZpOSSDUyn/2AVu0InfVdA0BTqESiYr8 0/PUoKW4jDfrHJJivNjeDEI= X-Google-Smtp-Source: ABdhPJzx4X87hBOmDUXTCdQGxrrPLWtsPtPdZ+ttjQXXNf3imUg661EZtyFoPlpWizR0zLY19C9m0w== X-Received: by 2002:adf:e390:: with SMTP id e16mr5503595wrm.217.1631418398155; Sat, 11 Sep 2021 20:46:38 -0700 (PDT) Original-Received: from localhost (tor-exit-2.zbau.f3netze.de. [185.220.100.253]) by smtp.googlemail.com with ESMTPSA id f23sm2670699wmc.3.2021.09.11.20.46.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 11 Sep 2021 20:46:37 -0700 (PDT) In-Reply-To: <87czpe4rj2.fsf@web.de> Received-SPF: pass client-ip=2a00:1450:4864:20::42a; envelope-from=nuclearspace@gmail.com; helo=mail-wr1-x42a.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:274579 Archived-At: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Michael Heerdegen writes: > I'm having problems to understand what you want to do and why. 1. To understand which variation of the patch I should post. 2. Hopefully to convince someone that this (func exp) was a terrible idea. > I see that a binding like (f (x y z)) is ambiguous. But isn't that a > minor problem? No. Syntax ambiguity is always a huge inconvenience. =2D If the purpose of cl-lib is to provide a compatibility layer for CL, then this is simply not compatible, on top of being ambiguous. =2D Such irregularities make code harder to port. =2D Such irregularities make it harder to write code programmatically. (This also addresses the argument about readability and why would anyone write code like this.) =2D Last but not least, such irregularities introduce a non-technical problem: whether something should be ported to cl-... as is, or a degree of artistic freedom is allowed. If yes, to which extent? Is it worth it to waste everyone's time arguing about each such instance in the future and synchronizing their perception? I'm absolutely certain it's not worth it. The sole point of standards is to be followed and thus remain reliable. Unless they can't be followed for technical reasons, in which case it should be noted that those are actually limitations, hopefully to be lifted one day. > And I don't understand why this minor annoyance justifies such a radical > measure, unless I misread that. If anything, it's actually (func exp) that is a radical departure from flet semantics. I do my best at offering my arguments but in fact it is one introducing something that is both (!) ambiguous and incompatible with CL who has (OK, had; it's too late for me now) the burden of proof. > would I have to use `cl--expand-flet' instead of `cl-flet' in the > future to get the same behavior as now? It depends. Sometimes it's better to use let. Sometimes, like in our case with cl-generic, an expander is the most appropriate. > That would be strange. With all due respect, I do not accept =E2=80=9Cstrange=E2=80=9D for an argu= ment and I never offer such arguments myself. =E2=80=9CStrange=E2=80=9D is subjective= . cl-flet is incompatible with flet (and rest of the points) --- that's objective. Even if I fail at convincing anyone that it should be dropped, I do wonder if this was indeed a Scheme influence. I conveyed all the reasons I could. If it's not convincing enough, there is no point in discussing this further, and I'll soon post a variation of the patch that keeps this syntax in cl-flet as is. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJLBAEBCgA1FiEEgu5SJRdnQOF34djNsr6xYbHsf0QFAmE9dXAXHG51Y2xlYXJz cGFjZUBnbWFpbC5jb20ACgkQsr6xYbHsf0Q7VxAAhrqgE7szkZ6ohBOKbhnC3+XX 5fvJ7XJQtODytlVP5dQ2GM+E4+kVSOZxkjxD31zEQ510Eqyoji/MYFEGykx9ej9Q zdhdpeCl9tmf4CVL6kFYKGlZy9KLKLHowM34cvcksJu6icODh/xz12hkT+D+9qE+ HICrcY2lUaWOMqGybJg3zpcUahEbPcc0BBLjWiIF+X2yd3dScukRQ/jQEzVDhs+7 4/2MNR3CipxGeS/kF0rTEBoJ9R0Hja+nqkB+/iQCVjNr7pfS7s/JJO0YI0s7sOjx aJfHS91XRNW8ZGpUy4EAVO6Gen4dzLqkYkO7u/rmcXKNJRv54k+pZlIVek4zLwKj 1i9ApIMBp7B98eXJyJQ7m1a69aqBSN8x4BjO1G8D0wVrHQE8cO8325RqL8fUKaKs 6t6iMLnTsybquG4+2SXF8ByRymfWltQGv/22Zt4IhbsA0ZxEcd9UH7QtEVB6bc0L stJJuf7FEqPXhdiPnnSDYZOFZYQbWC6TnvR6BkNwWw91lWFFXKGH/+kCL872YVS2 jMgCBMcb6rEPCrtUd1JkG9x6vUi3WT2xMDycirUXbMY8xI6/3CDiXfmQiWiG5PaZ soKYADbXAVpdpuJscgmxPFhotuORr1zMkHPIsWQu2Yn5ET36yBZdkpCV6ml2i5P1 yg4JD1zMW8ZvZ59EA5M= =UqxP -----END PGP SIGNATURE----- --=-=-=--