From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Barry Fishman Newsgroups: gmane.emacs.devel Subject: Re: Instead of pcase Date: Sat, 02 Dec 2023 12:02:52 -0500 Message-ID: <7n34wk1qrn.fsf@ecube.ecubist.org> 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> <763f067b-4ca9-1eba-9f3c-424c38589e9c@gutov.dev> <87v89ht2s4.fsf@linux-m68k.org> <87jzpxq8oi.fsf@posteo.net> <87plzoap38.fsf@dataswamp.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="8486"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: emacs-devel@gnu.org Cancel-Lock: sha1:e09H67VgA+3a8F04VVOtGcTYKkA= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Dec 02 18:03:53 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 1r9TPE-00022j-7A for ged-emacs-devel@m.gmane-mx.org; Sat, 02 Dec 2023 18:03:52 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r9TOb-0007dP-V3; Sat, 02 Dec 2023 12:03: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 1r9TOW-0007cC-9t for emacs-devel@gnu.org; Sat, 02 Dec 2023 12:03:09 -0500 Original-Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r9TOU-0003oM-4N for emacs-devel@gnu.org; Sat, 02 Dec 2023 12:03:07 -0500 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1r9TOQ-0000uO-U6 for emacs-devel@gnu.org; Sat, 02 Dec 2023 18:03:02 +0100 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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:313471 Archived-At: On 2023-12-02 11:14:19 +01, Emanuel Berg wrote: > I thought pattern matching with in particular Haskell was > neurotic because one would spend more time on it than one felt > was called for, but I think Haskell invited to that kind of > fiddling, I always thought of Elisp including `pcase' to be > much more calm and relaxed? Your sense of calm and relaxation about `pcase' does not seem to be shared by a lot of people, who think of it as overly complex and ugly. To me Haskell starts with just Scheme changed to fix every criticism that has been make about Lisp whether it was valid or not. But they end up with something very different. The Haskell pattern matching construct, unlike `pcase' is broken into three independent steps. First the declaration of types for each of the variables to be extracted, although this is sometimes done automatically by the (static) type system. Then, the list of accepted patterns, given in the form of constructors using the variables to build the patterns being matched. Then possibly a list of tests to be tried on the values of the matching variables. And finally for the first valid "pattern" and "guard" test, the code is execute using the extracted variables. My example `proto-case' more resembled this, although I did not allow for multiple guard clauses for each constructor match. It did not use back-quoting, but instead required used a prototype constructions add those needed for each atomic type, or type class (in the sense of CLOS). This is less powerful than `pcase', but didn't require a subset of back-quoting merged with modified type specifier syntax in one new `pcase' specific language. But comparing what goes on in Haskell `case' vs. any pattern matching in a Lisp like language is hard, primarily because Haskell evaluation rules are so different from those of other languages. Haskell is a curried, non-strict, statically typed, syntactically complex language, so can reorder code in ways that are very different than Elisp. So simple Haskell code can becomes very complex in Lisp, and simple Lisp code can be very complex in Haskell. But my issue with `pcase' is more related to that people will tend to use it by copying and pasting its example cases (which they don't fully understand), in places where a simpler syntax would be used. This is partly because Elisp does not have the simpler Common Lisp `typecase' (it does have the discouraged `cl-typecase') and a more flexible 'case' and Scheme like `cond' constructs that are easier to understand and use, and work in most situations. Yes, you can come up with `pcase' situations that are shorter or more powerful, but its seems that the `pcase' proponents don't seem to be able to provide obvious examples which show that power. Without those examples people will tend to cut and paste code in places where simpler more readable code could be use. Their use of pointing to existing Elisp code using `pcase' involves understanding the context of the code. This makes giving the any alternative examples harder to do, because it require understanding and possibly restructuring more complex situations. Its should be the burden on the proponents of a new feature to provide useful examples of their construct in a simple explainable context, and not the alternative. I see the Haskell pattern matching given very little time in introductory Haskell books, because its well formulated and easy to understand in the context of the language. Of course understanding Haskell, especially after being exposed to most other languages, requires a mental reset that is not easy. It took me about four re-reads to gain any understanding what was going on, but I was burdened with having used a lot of other languages. It was the first time I couldn't just recast things in terms of how I would do them better in Lisp. But using a constructor based rather than a backquote-splice/type-specifier approach seems (to me) simpler to understand. Or at least give an example of code (in a simple context) to show `pcase' in something that shows its full power. -- Barry Fishman