From mboxrd@z Thu Jan  1 00:00:00 1970
Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail
From: Philip Kaludercic <philipk@posteo.net>
Newsgroups: gmane.emacs.devel
Subject: Re: cond* vs pcase
Date: Tue, 06 Feb 2024 19:39:07 +0000
Message-ID: <87v871qt5w.fsf@posteo.net>
References: <DU2PR02MB10109F1CBA5F7A8D78A597A5D96472@DU2PR02MB10109.eurprd02.prod.outlook.com>
 <E1rX1UK-0005Ip-Ff@fencepost.gnu.org> <87il32iwmm.fsf@posteo.net>
 <E1rXO89-0003Ll-3B@fencepost.gnu.org> <87o7cttu4l.fsf@posteo.net>
 <E1rXPEL-0000nD-Iw@fencepost.gnu.org> <87o7cts9nc.fsf@posteo.net>
 <E1rXQjk-0000D0-6y@fencepost.gnu.org>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214";
	logging-data="26752"; mail-complaints-to="usenet@ciao.gmane.io"
Cc: arthur.miller@live.com,  emacs-devel@gnu.org
To: "Alfred M. Szmidt" <ams@gnu.org>
Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Feb 06 20:39:59 2024
Return-path: <emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org>
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 <emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org>)
	id 1rXRIU-0006kE-K3
	for ged-emacs-devel@m.gmane-mx.org; Tue, 06 Feb 2024 20:39:58 +0100
Original-Received: from localhost ([::1] helo=lists1p.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.90_1)
	(envelope-from <emacs-devel-bounces@gnu.org>)
	id 1rXRHo-0004Al-EP; Tue, 06 Feb 2024 14:39:16 -0500
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 <philipk@posteo.net>)
 id 1rXRHl-0004AL-Mm
 for emacs-devel@gnu.org; Tue, 06 Feb 2024 14:39:13 -0500
Original-Received: from mout02.posteo.de ([185.67.36.66])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <philipk@posteo.net>)
 id 1rXRHj-0006RS-Fs
 for emacs-devel@gnu.org; Tue, 06 Feb 2024 14:39:13 -0500
Original-Received: from submission (posteo.de [185.67.36.169]) 
 by mout02.posteo.de (Postfix) with ESMTPS id EE3A9240105
 for <emacs-devel@gnu.org>; Tue,  6 Feb 2024 20:39:08 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
 t=1707248349; bh=CscAliZUqjcPx1jurb1k7jdIRmT8rBkUY2ooS0PemKo=;
 h=From:To:Cc:Subject:Autocrypt:OpenPGP:Date:Message-ID:MIME-Version:
 Content-Type:From;
 b=oHynWpS2ycDr77c6WQxCiwhnWcy8Oa2A12yu99wcwF5kapg7FzC8NZSrVa5GClu6u
 9GmObILH8ldjVyA7vrErO1MvCcr8jKcq3K+hrxybGIzrH7nz8zcXKt2OGh3M7PwBaJ
 SuODMfJvn9Qh9M3uIXqfILG3CgGmuzPfze+lHP2OJ9kZQPOrPDCZgMUJpOQg+2HDpN
 +XaJK3EhWPOqlnx+tmQADp3Bsep6KytHYJAxMEXsKuOGc8UKgchJEGdqEQL4t4c6MP
 zr2BA9PYU3j1RaRs68641+7bwHmYYCMv82inwzUeEAx3+aA2mu4c6bE8W4hiSW094H
 w2N3Q+r8Z2rag==
Original-Received: from customer (localhost [127.0.0.1])
 by submission (posteo.de) with ESMTPSA id 4TTtq03V0Zz9rxF;
 Tue,  6 Feb 2024 20:39:08 +0100 (CET)
In-Reply-To: <E1rXQjk-0000D0-6y@fencepost.gnu.org> (Alfred M. Szmidt's message
 of "Tue, 06 Feb 2024 14:04:04 -0500")
Autocrypt: addr=philipk@posteo.net; keydata=
 mDMEZBBQQhYJKwYBBAHaRw8BAQdAHJuofBrfqFh12uQu0Yi7mrl525F28eTmwUDflFNmdui0QlBo
 aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0
 ZW8ubmV0PoiWBBMWCAA+FiEEDg7HY17ghYlni8XN8xYDWXahwukFAmQQUEICGwMFCQHhM4AFCwkI
 BwIGFQoJCAsCBBYCAwECHgECF4AACgkQ8xYDWXahwulikAEA77hloUiSrXgFkUVJhlKBpLCHUjA0
 mWZ9j9w5d08+jVwBAK6c4iGP7j+/PhbkxaEKa4V3MzIl7zJkcNNjHCXmvFcEuDgEZBBQQhIKKwYB
 BAGXVQEFAQEHQI5NLiLRjZy3OfSt1dhCmFyn+fN/QKELUYQetiaoe+MMAwEIB4h+BBgWCAAmFiEE
 Dg7HY17ghYlni8XN8xYDWXahwukFAmQQUEICGwwFCQHhM4AACgkQ8xYDWXahwukm+wEA8cml4JpK
 NeAu65rg+auKrPOP6TP/4YWRCTIvuYDm0joBALw98AMz7/qMHvSCeU/hw9PL6u6R2EScxtpKnWof
 z4oM
OpenPGP: id=7126E1DE2F0CE35C770BED01F2C3CC513DB89F66;
 url="https://keys.openpgp.org/vks/v1/by-fingerprint/7126E1DE2F0CE35C770BED01F2C3CC513DB89F66";
 preference=signencrypt
Received-SPF: pass client-ip=185.67.36.66; envelope-from=philipk@posteo.net;
 helo=mout02.posteo.de
X-Spam_score_int: -43
X-Spam_score: -4.4
X-Spam_bar: ----
X-Spam_report: (-4.4 / 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_MED=-2.3, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001,
 T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-BeenThere: emacs-devel@gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Emacs development discussions." <emacs-devel.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-devel>,
 <mailto:emacs-devel-request@gnu.org?subject=unsubscribe>
List-Archive: <https://lists.gnu.org/archive/html/emacs-devel>
List-Post: <mailto:emacs-devel@gnu.org>
List-Help: <mailto:emacs-devel-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-devel>,
 <mailto:emacs-devel-request@gnu.org?subject=subscribe>
Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org
Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org
Xref: news.gmane.io gmane.emacs.devel:315946
Archived-At: <http://permalink.gmane.org/gmane.emacs.devel/315946>

"Alfred M. Szmidt" <ams@gnu.org> writes:

>    >    > Because your not doing pattern matching, you're comparing against a
>    >    > set of strings/symbols/numbers/....
>    >
>    >    Simply because pattern matching is a more powerful generalisation,
>    >    capable of expressing case-distinction; in the end it compiles down to
>    >    almost the same code anyway.
>    >
>    > Are you suggesting that COND/CASE/... and other "trivial" matching
>    > constructs should be replaced with PCASE/COND*?
>
>    No, just that using pcase in these cases isn't wrong.
>
> Then we disagree on a fundamental level.  This is just like like using
> EQUAL when comparing stricly strings is not the right tool for the
> job.

"Alfred M. Szmidt" <ams@gnu.org> writes:

>    Also interning strings just for the purpose of comparing them with eq or
>    eql is questionable...
>
> So is pattern matching over characters, numbers, and other simple
> types... 

In both cases here I think that there is a fundamental distinction
between functionality that is generic at compile-time and at run-time.
While `equal' vs `eq' is not pretty, the main issue for me here is that
you might accidentally compare and equate two string or lists that are
not the same object, which you sometimes don't want to do.  Otherwise it
is not really slower than using `eq', if that is what concerns you:

--8<---------------cut here---------------start------------->8---
(benchmark-run 10000000
  (eq 'foo 'bar))
;; (2.589085844 0 0.0)

(benchmark-run 10000000
  (equal 'foo 'bar))
;; (2.611292045 0 0.0)
--8<---------------cut here---------------end--------------->8---

The pattern matching code is all generated at compile-time, and even
uses the `eq' to compare symbols, instead of the less specific `eql'
(!).

Yes, this might be a fundamental disagreement, but I still don't think
that using more abstract means to solve a problem is inherently wrong.
It might be a personal preference, but nothing we could derive a general
rule from -- which is fine.