From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: Instead of pcase Date: Fri, 1 Dec 2023 13:28:09 +0000 Message-ID: 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> <83fs0navpj.fsf@gnu.org> <838r6ebfhw.fsf@gnu.org> <83msuu9m2y.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15967"; mail-complaints-to="usenet@ciao.gmane.io" Cc: owinebar@gmail.com, rms@gnu.org, dmitry@gutov.dev, philipk@posteo.net, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Dec 01 14:26:24 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 1r93XE-0003wS-9K for ged-emacs-devel@m.gmane-mx.org; Fri, 01 Dec 2023 14:26:24 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r93WU-00042U-D5; Fri, 01 Dec 2023 08:25: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 1r93WK-000429-27 for emacs-devel@gnu.org; Fri, 01 Dec 2023 08:25:29 -0500 Original-Received: from mail-lf1-x130.google.com ([2a00:1450:4864:20::130]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1r93WA-0004sw-M6; Fri, 01 Dec 2023 08:25:24 -0500 Original-Received: by mail-lf1-x130.google.com with SMTP id 2adb3069b0e04-50bc053a9a7so3074050e87.1; Fri, 01 Dec 2023 05:25:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701437111; x=1702041911; darn=gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Ve7lR6YAQ2tBNhTUZbBPg2NWU4r0xI/Cim75HNtmhMM=; b=JcVEH470/ADYhNhODnO8hkkZsCve1hLrFCuB+NdQfnKC1Grx2ML2o+fB+AqAL7Lduq 4fs1iF5agWIXlivJdiJJE/B8wk0A4EfryIM14BaMYDEkRF7z6CjmIa8WyJPHQXNstkiD u5JUNMPExDKPjRehHCtOooYqjJ1IkOE46QWRqTFohTq2GukvB+gAItkODYwlKmxNrSlT G5AzUSjH2/ZBfevawXrP8fZUwd7ZvB4jvpa+sNaGdy61Hj5gmfnFkdjhNS8z/vXYasYC OQe8OEv5lcAkogaY0bUzLUbOwY4c9DQPbGQVgrXAvGbNjdTWI+Z/PWdhDLlORxcGFUAI OTaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701437111; x=1702041911; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Ve7lR6YAQ2tBNhTUZbBPg2NWU4r0xI/Cim75HNtmhMM=; b=sdzyG/vLYTnIDqqNC16wy6l1Uj/+sMTmPiQHZRxP34RQlLwRgWKGYyvw7vBsgcjrLJ b5EtCFKWH0RCzQiz3aYpr/O4FXwxPqShisFblBEJXmCV3CCaOMZGXbZeJGWc2HcuaDRF OwyNaWuQJfCM2Zo3GJDsuLRyPh2+En0AFUtBlyfFyABsjvyIXhbwrg7JgSduShIkRnjJ MOCqkwbs+i3MyEHK/YWjkCihnUK6sDZWYd71c8FW3/OkUwaArcIGkh5j9Qn7oXLnehS3 Q2Cn9ewDOLKc34+bv2ctzoXitK/Fr2JnTcKCo3wTOtCSxY2o2q7zPqi28fzEUhHo8Wzj ms0Q== X-Gm-Message-State: AOJu0Yzq6daBGmtO45vtJNR1FP48F8j1aQ5WQYPEsR6jXQxD/EU2Ocwi dYwdh6SFk3iNLyoHi8xO/0Mos1133RGNqHmTMHSEe0Dr X-Google-Smtp-Source: AGHT+IH5m673MYTlB8i2MUWezZvNUYyqD5Jv+3nNH3afAdMxcov2PgHrtUWKpT6irt9zSR+opdvtfA3YaShyXEHciD4= X-Received: by 2002:ac2:5e83:0:b0:50b:d192:4d47 with SMTP id b3-20020ac25e83000000b0050bd1924d47mr425468lfq.32.1701437111330; Fri, 01 Dec 2023 05:25:11 -0800 (PST) In-Reply-To: <83msuu9m2y.fsf@gnu.org> Received-SPF: pass client-ip=2a00:1450:4864:20::130; envelope-from=joaotavora@gmail.com; helo=mail-lf1-x130.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, 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:313439 Archived-At: On Fri, Dec 1, 2023 at 11:52=E2=80=AFAM Eli Zaretskii wrote: > > So, in these emails, I'm trying to explain to you how to change your > > view of these pcase constructs in a constructive way > > This is a misunderstanding: I'm not expressing _my_ views. I'm > expressing the views of someone who bumps into this code the first or > the second time, and/or didn't yet have the advantage of someone > giving them "a piece of insight" that caused you to change your mind. > IOW, I'm expressing _your_ views before you changed your mind. Fair enough. Though, given your statements about the "redundancy" of '.' and its different "magic" role in 'pcase' vs "elsewhere in Lisp" one can be easily led to believe the contrary, because both those statement= s are demonstrably false (at least in the only interpretation of them I could find). > In Emacs development and maintenance, being able to look at stuff from > the POV of an innocent user or Lisp programmer is sometimes required > to realize the true impact of some constructs and features. We cannot > regard that only from the height of our own knowledge and experience, > which usually far surpass those of many Emacs users and programmers. Again, this is perfectly fair. Elisp, like many other languages, has constructs for different levels of proficiency. You wouldn't refrain from using C functions or C typedefs just because it requires more knowledg= e about the how the C language than a simple untyped program where everything is inlined in main() and every piece of data is in an array. > If this is that easy, then why do we need no less than 120 lines to > describe pcase in the doc string, and no less than 600 lines to > document its features in the ELisp manual? _I_ didn't write that docstring. Maybe the docstring and the manual should start by making the easy and common use cases prominent and visible, just like I tried to do in that 10 line paragraph. As you know, writing good docstrings and manuals is a challenge in itself. But that shouldn't be an argument against the validity of the tool being described. > understand that. None of that is true. All I'm trying to say is that > there _are_ inherent problems in the DSL whose knowledge is required > to understand code written using pcase, and that you and others should > recognize these inherent problems are real The only _inherent_ difficulty I recognize in pcase DSL's is the _inherit_ difficulty in understand the backtick-and-quote in so-called "normal Lisp". > , even though you have > overcome them, and anyone could overcome them given enough time and > experience. My point is that "time and experience" isn't necessary to understand the most common uses of pcase's DSL. That one piece of insight paired a knowledge about how backtick-and-quote works "in normal Lisp" for list construction will suffice to fully master pcase's list destructuring abilities.