From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Adam Porter Newsgroups: gmane.emacs.devel Subject: Re: cond* Date: Sat, 13 Jan 2024 00:32:03 -0600 Message-ID: <8317f5d8-f431-4be9-b5f0-0a6cf8fe2222@alphapapa.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22558"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: emacs-devel@gnu.org, yantar92@posteo.net To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jan 13 07:33:04 2024 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 1rOXZn-0005d4-9L for ged-emacs-devel@m.gmane-mx.org; Sat, 13 Jan 2024 07:33:03 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rOXZ0-0003Qt-Mq; Sat, 13 Jan 2024 01:32:14 -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 ) id 1rOXYx-0003QM-AW for emacs-devel@gnu.org; Sat, 13 Jan 2024 01:32:11 -0500 Original-Received: from purple.birch.relay.mailchannels.net ([23.83.209.150]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rOXYv-00026F-95; Sat, 13 Jan 2024 01:32:11 -0500 X-Sender-Id: dreamhost|x-authsender|adam@alphapapa.net Original-Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id D9B558427C8; Sat, 13 Jan 2024 06:32:05 +0000 (UTC) Original-Received: from pdx1-sub0-mail-a249.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 71A1F8427E8; Sat, 13 Jan 2024 06:32:05 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1705127525; a=rsa-sha256; cv=none; b=VeQnD/5mr46AFYFKipqX+gnVCo9b3f8j9F1h1j0nt5zFpafTW/j2sf9nT+icXhlrrm2NY1 02hoPtoVIdKtSBCpgin+VssbBe96cWt6Oy+ZULi/j0jVkMZAOu22DJyD1MEbKCqYmm8fQg kXaXb3lVpYsqwWDGICQUbD/5l02z6txIwpgg5xqQatkZavEZw66S5kl+YacBTA7OtspNqg wzqRbZX9eOHMLPiLQ1eM+rDhXd7IjSLrWHlgsruTkNTAFFeBgHW/NfAXPZaf5yr4XuDpaQ VAob6gXup+QA0D1UHDZKSdPwzm27UVnr7N3wENM2MKEoXwLVuSbq/zhwKqvOHw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1705127525; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=uPYgXSlDMQ8s3eVOk+n+NApDooBeqI/0ACBkuswlyD0=; b=kqT3rf/r9HfruDilo1VRsHWJAAN+G1i390q0LE345ABLv2JbMK4zpxIlxzji1JvB+NxXAQ 5t38f8EbQR0iC3banKCTau8eXfo0g4D566WLoF2xu/839a1dVd9UU+VK03Cwf4m8kYFsE0 5WhVVS48QCZhUZ26vxeppLLy6TvY6/Yzky21gcLQsQJW6djn3ni5YVfZ/WPAYGr0tUH2yW oDHBYcBtaxL7nxgB1RIevPFeg+T3Fr7UhTvmxuTd6/MTDRFjkWn3912I2us4N3+usrMkbJ epDrdQnj6qdMjj9R00YIesILs0IQKKmxDYMNRLSv8bF28WVTIImoEenlpDuISw== ARC-Authentication-Results: i=1; rspamd-568947cb6c-vd7hj; auth=pass smtp.auth=dreamhost smtp.mailfrom=adam@alphapapa.net X-Sender-Id: dreamhost|x-authsender|adam@alphapapa.net X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|adam@alphapapa.net X-MailChannels-Auth-Id: dreamhost X-Bored-Bored: 1c003a4b5e0dc275_1705127525706_1089217934 X-MC-Loop-Signature: 1705127525706:4280752050 X-MC-Ingress-Time: 1705127525706 Original-Received: from pdx1-sub0-mail-a249.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.124.147.182 (trex/6.9.2); Sat, 13 Jan 2024 06:32:05 +0000 Original-Received: from [10.45.1.238] (unknown [45.131.192.7]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: adam@alphapapa.net) by pdx1-sub0-mail-a249.dreamhost.com (Postfix) with ESMTPSA id 4TBpTw5q0gz6D; Fri, 12 Jan 2024 22:32:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alphapapa.net; s=dreamhost; t=1705127525; bh=uPYgXSlDMQ8s3eVOk+n+NApDooBeqI/0ACBkuswlyD0=; h=Date:To:Cc:Subject:From:Content-Type:Content-Transfer-Encoding; b=klsfREf8sY1HW1qhr683SR1/A2Hwnw071Vo+SHdfQ/ckwW9y87DOhFk4iDlfHFdx6 iZrzVU6fRV3LtlPIiShVQGMqt3ZcHqaMjALIVYN0a03zustuTjIzk2BGswwu5usWcO Uuvu0Whvba3vCyMYK2Z4yhenREcfyd3MvLc3pEm4JNfY4viQBzcqPDheQPSwMKsBlr pIaliHv8yLF8KlNxear6jLm+2B/I41q6uIB5CGjZJST07YMDV5wzJwOrL5tM2A1hyk kuwYhd1Xbg5oo4NJvkM6kXzkBfIy87c13Zwgxtm3sAf/NwJMqcsGKhvSwIRfGICRi+ KJO5lCpdpLZgA== Content-Language: en-US In-Reply-To: Received-SPF: neutral client-ip=23.83.209.150; envelope-from=adam@alphapapa.net; helo=purple.birch.relay.mailchannels.net X-Spam_score_int: -12 X-Spam_score: -1.3 X-Spam_bar: - X-Spam_report: (-1.3 / 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no 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." 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:314922 Archived-At: > (symbolp x) is simpler and more natural than the pcase equivalent, > which I believe would be (and (pred symbolp) x). People seem to have > accepted the latter, without criticizing it as unnatural. I think that is an apples-to-oranges comparison. This pcase form: (and (pred symbolp) x) is specifically a pcase form. It does two things, and--crucially--it does them separately and explicitly: 1. It tests the EXP with the predicate `symbolp'. 2. If the test is non-nil, it binds the EXP to `x'. The list `(pred symbolp)' is obviously not a normal expression, because `symbolp' is a predicate function and is unquoted in this list (i.e. there is no `symbolp' variable bound). In contrast, this cond* form: (symbolp x) looks like a normal expression calling the function `symbolp'; and, in a sense, it is, because that will happen. But that same form also binds the variable `x' after testing its to-be-bound value with the predicate `symbolp'--yet the binding is not explicit and separate, but implicit and combined. Contrast that also with a pcase `guard' form, like in: (and x (guard (symbolp x))) That also does the same thing, but again, the binding and testing are separate and explicit. And it provides the additional benefit of the `guard' form being a normal expression, so it could include other parts, like: (and x (guard (and (symbolp x) (string-prefix-p "foo" (symbol-name x))))) ISTM that the most potentially confusing aspect of that pcase form is that `and' is effectively used to denote binding; and I think that could be mitigated by offering an alternative, optional keyword to surround bindings, to make them appear more explicit. > I think they will accept (symbolp x) also. I think that people will > get used to this once they start actually using cond*. By the same token, people could get used to pcase's design once they start using it. But pcase's binding and testing forms are more explicit and look less like normal expressions, which makes it potentially less confusing to users. We often bemoan the addition of various libraries to Emacs and ELPA that seem to do what existing ones already do, but in slightly different ways. Why not improve pcase to solve these minor shortcomings, instead of adding another library that does some similar things, in slightly different, incompatible ways, while not even offering as much functionality as pcase? (e.g. as I've mentioned, pcase can destructure maps, structs, and EIEIO objects, and is extensible by other libraries--it's an incredible tool that I sorely miss when working in environments outside of Emacs Lisp.) --Adam