From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Instead of pcase Date: Mon, 20 Nov 2023 03:15:09 +0200 Message-ID: <9291c349-3821-9a9a-6303-463e0f957b15@gutov.dev> References: <87fs169mjj.fsf@posteo.net> <093f11a1-57c2-5e56-d39b-26fef1c67cbb@gutov.dev> <25942.25061.217864.329049@retriever.mtv.corp.google.com> <87zfzdcz6z.fsf@posteo.net> <87zfza2aq2.fsf@web.de> <7nmsv9zq6u.fsf@ecube.ecubist.org> <7nv89x5tsi.fsf@ecube.ecubist.org> 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="3907"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 To: Barry Fishman , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Nov 20 02:16:26 2023 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 1r4stk-0000o2-Vh for ged-emacs-devel@m.gmane-mx.org; Mon, 20 Nov 2023 02:16:26 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r4st0-0001Ib-Mb; Sun, 19 Nov 2023 20:15:39 -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 1r4ssk-0001ID-Ru for emacs-devel@gnu.org; Sun, 19 Nov 2023 20:15:28 -0500 Original-Received: from wout5-smtp.messagingengine.com ([64.147.123.21]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r4ssh-00045H-Pi for emacs-devel@gnu.org; Sun, 19 Nov 2023 20:15:22 -0500 Original-Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 9C5C8320096F; Sun, 19 Nov 2023 20:15:14 -0500 (EST) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Sun, 19 Nov 2023 20:15:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm2; t= 1700442914; x=1700529314; bh=t491Cif9BVRKV6nHSIn/fkxAzsVVgpM5BGt CPD3rdT8=; b=A8auwES+AUCWAx+xDbNX290vICOcPdqsg0pVdgyk9A9vbVxhJxP ivHptuCNete+BX87VyzzjtjwkASxxiJKbFDhJtpNwdMx4AVZNLB8hU0DxM+Tsv4i o08mpqORtVQnSy5aa3vlq/763vTeXtdv23w42mZXyOfbxdlmvSOLRcaeidgI/N8X G1vbY8XarUrQKMdIg9HVvcLYDUEPipNkJpxBguBPcj6k5+3RK5lIB+jMeqms1KC2 PhauNurTxtydh6FBdtBKg9afDEjnTMlIKE0QqoDjSAsvGAVnX1L1zhNvx6VZSSSb UnGWaK9DXZ44hNZ+LmHi4GIli8taDKrhAQA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1700442914; x= 1700529314; bh=t491Cif9BVRKV6nHSIn/fkxAzsVVgpM5BGtCPD3rdT8=; b=p CygHGcsyXem+bAPJ/3rXw1YTq5eoe3EIg4qi+aHyCVS8cv8xE+cRKgxn4YfWzdyl wvRhZdNyZZRtHlW3rdpk5+/t0ItzDwJ4567Of/uPtt5bajWrYNqETQIl58GSzpxh OEN1rQEig1zndO7BnKNNRc3szr9L77rEO5bgqdOgF5JmH0E9ZjFSfoY14eMMh7Eq qGXzK78Zx/aHfvfeOq87HqzBWHvfQa9qS9T36AI0hVnMb5B4TvuvpDuEh+0Tkfr1 wDWoeB0fGQDxQUY8TT1I+hg4kGu6hegzDFGsJrfuokYA3ur6d3Tr616jGRetLfGx YZyFHLUxtCtQJRCrxiuwA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudeghedgfeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvfhfhjggtgfesthejredttdefjeenucfhrhhomhepffhmihht rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth gvrhhnpeeghedthedujeeiteeutddtjeekheejteeukeehffdutdejuedvfeevueeviedu udenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumh hithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 19 Nov 2023 20:15:12 -0500 (EST) Content-Language: en-US In-Reply-To: <7nv89x5tsi.fsf@ecube.ecubist.org> Received-SPF: pass client-ip=64.147.123.21; envelope-from=dmitry@gutov.dev; helo=wout5-smtp.messagingengine.com X-Spam_score_int: -75 X-Spam_score: -7.6 X-Spam_bar: ------- X-Spam_report: (-7.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, NICE_REPLY_A=-3.74, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-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." 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:313026 Archived-At: On 19/11/2023 23:15, Barry Fishman wrote: >> Haskell is notable for using the same (or similar) syntax for >> destructuring as it uses for constructing expressions. >> >> pcase actually follows that practice with backquotes and commas. > > Really? I thought back-quoting was used (as an alternative way) to > construct nested lists, to express more simply the piecing together and > concatenating nested list pieces, particularly in macroes, and its > expansion at compile time is fairly obvious. > > I guess what pcase is trying to do is the similar, The reverse, to be more exact. > but it is expressing > something that, to me, seem far more complex to use. I don't blame you, FWIW. But I've yet to see a "simpler" solution which would provide comparable functionality. > Its also mixing "destructuring" and "guard"s, all in one "super" domain > specific language. > > Like loop, it can be powerful, but intimidating to people that don't use > it a lot. But its usefulness to those that know it, encourages its > use in the code base. > > But exiting Lisp destructuring via destructuring-bind and lambda > arguments, don't use backquoting. They also don't provide any pattern matching of case-like functionality. When you don't need a way to distinguish literals from variables, (un)quoting is indeed not needed. > One thing I did change was to reverse the defmethod style of (variable > type) to (type variable) to try to simplify recursion in the typeproto > syntax. > >> And in both matching and destructuring are done in the same expression >> (the presence of the latter is determined by whether a pattern >> contains variable bindindgs). >> >>> If x is a list with its first element a string "foo" and the second an >>> integer, remove it from x and add the second element to total: >>> (proto-case x >>> ((list* (string name) (integer count) (t rest)) >>> (string-equal name "foo") >>> (set! total (+ total count)) >>> (set! x rest))) >>> This is just one of many other ways one could setup a matching >>> expression in elisp, the best is a balance between implementation >>> efficiency and readability. >> >> And this divorces matching from destructuring. I suggest you try >> rewriting one of the more complex pcase usages into this syntax and >> see what people think of the result. > > You want me to guess what you have in mind? I have no idea. I meant that you could try to take an example of a complex usage of pcase (one that seemed complex to you), some big expression or at least one that exhibits most of pcase's functionalities, and try rewriting it using an alternative syntax. And then judge for yourself, and then maybe poll others, which solution looks more readable and easier to understand. > I'll take the example pcase code from the Emacs manual: > > (pcase (get-return-code x) > ;; string > ((and (pred stringp) msg) > (message "%s" msg)) > ;; symbol > ('success (message "Done!")) > ('would-block (message "Sorry, can't do it now")) > ('read-only (message "The shmliblick is read-only")) > ('access-denied (message "You do not have the needed rights")) > ;; default > (code (message "Unknown return code %S" code))) > > This is a simple use case, so its hard to use to draw any conclusions. > > This is mostly value handling for a known type, which is to me a > different problem than destructuring, and be handled better by a > generalized value case structure. But still: > > (let ((msglist > '((success . "Done!") > (would-block . "Sorry, can't do it now") > (read-only . "The shmliblick is read-only") > (access-denied . "You do not have the needed rights")))) > (proto-case (get-return-code x) > ((string msg) t (message "%s" msg)) > ((symbol sym) t (let ((pair (assq sym msglist))) > (if pair > (message (cdr pair)) > (message "Unknown return symbol %S" sym)))) > ((t code) t (message "Unknown return type %S" code)))) > > In this situation pcase situation is a slightly better, to my > sensibility's. [Now that pcase is written] Indeed, I don't see an improvement either. I'd say it looks worse because of the slight increase in verbosity, but they're close enough. That's why I suggested picking some relatively complex example to rewrite: more potential to show a difference.