From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lynn Winebarger Newsgroups: gmane.emacs.devel Subject: Re: Instead of pcase Date: Sat, 2 Dec 2023 13:01:24 -0500 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> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000fc2cdf060b8aac29" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23198"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Dmitry Gutov , Philip Kaludercic , emacs-devel To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Dec 02 19:02:29 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 1r9UJw-0005n6-Iw for ged-emacs-devel@m.gmane-mx.org; Sat, 02 Dec 2023 19:02:28 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r9UJB-0006Vu-Rl; Sat, 02 Dec 2023 13:01:41 -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 1r9UJA-0006VN-BK for emacs-devel@gnu.org; Sat, 02 Dec 2023 13:01:40 -0500 Original-Received: from mail-pj1-x1033.google.com ([2607:f8b0:4864:20::1033]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1r9UJ8-0003EP-Gs; Sat, 02 Dec 2023 13:01:40 -0500 Original-Received: by mail-pj1-x1033.google.com with SMTP id 98e67ed59e1d1-28659b38bc7so1648462a91.0; Sat, 02 Dec 2023 10:01:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701540096; x=1702144896; darn=gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=vIR6Cftsnh2+LGxx7TLjNit9DTe5r/bsxyFgVF3A0p0=; b=SkiOqiR97OXuiOk0n9+04Hlo8yHWX+5n2qyIlSksClP0AvxmgffHxgliWDyeGRIOYv oBI4/IXy76iiB2ZrhpczoQVj38Qwhn6AyNjhE5H8diwI5c9sk1eZMEMDKtFb8AZGWoBG yCLHC5wMTi6n2xZZc2vyqnxHzsJVlo+3C7b7zgepT63tL70+nT9NbgQIAshhn4pEDT4y XV//avEY6M9bpO+FwpQUJU67/MPwxlho6XG8zaa4g0SL/HG2ggEtjQXJxgQUDOIyw7ct 9RYs+6bFVI042Em02B5TAghEMwvoLaQ5t+9vHMH22baigor4KehJRwzNFTi/Fj6Dbf+H PUHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701540096; x=1702144896; h=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=vIR6Cftsnh2+LGxx7TLjNit9DTe5r/bsxyFgVF3A0p0=; b=YW17U7FkDoSWBRMkAsaO6uHSaIyvFY3fRKFsxXyI4PCzBmceLO0GbRiDYWlly57o9N acw/onwuHyjf2757bBmemYwtxRqoJSeORxDQjlpg6hyV5MN6lvpZVefJT0qEFDT0uMYS Cs73Ed0k+TCV0xwWJRzN3QjSaTN93T6wHW4Bd4KTlMHLYExlJzlI19Bzcv6YytBnMe0t W+NbF/qTlqAVYagrPYaY8L5hXISUD0jl6ihRgwQDtv60velUuQ3W6zPG9m2BXpgXWJj8 4VkWoX1NW0C2tCIKypQ+GIfMGrfkCTJb3WeeqAPQXLF9pdiJ1SMFk9bkW7BO3IYKhy1A NLMA== X-Gm-Message-State: AOJu0YyU4j4x+qfqorTHSpEdgnLf/GPTBeTDszRjUiA+/EO6aGsrPHxa KiVFvQcGFkfTheZ4+yBfKyDxflOhk/EASgNfCrC9UL/S X-Google-Smtp-Source: AGHT+IEtnmIYi6jfdZSD1vCdDTFDjWsseHYfOKE50D/Ww8KeSUU44yxvcwqjpwXbdbD3EXzFBUzcHhuPfwYcrK/i/Sg= X-Received: by 2002:a17:90b:3509:b0:286:8a9c:6804 with SMTP id ls9-20020a17090b350900b002868a9c6804mr314924pjb.44.1701540095862; Sat, 02 Dec 2023 10:01:35 -0800 (PST) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::1033; envelope-from=owinebar@gmail.com; helo=mail-pj1-x1033.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, HTML_MESSAGE=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:313473 Archived-At: --000000000000fc2cdf060b8aac29 Content-Type: text/plain; charset="UTF-8" On Fri, Dec 1, 2023, 10:20 PM Richard Stallman wrote: > > > But a person who is just starting to look at this code, and reads > that > > > function first, is likely to be impeded in starting to reach that > sort > > > of understanding. > > > > > > I have to respectfully disagree - dotted pair notation is a pretty > > fundamental part of LISP syntax, regardless of dialect. > > That is true, but it is not pertinent to my finding that pcase code > confusing. I know what dotted pairs mean, but I was not sure what > they meant in pcase patterns. > > Likewise for Eli. It is unkind and unhelpful to lecture him about > what dotted paris are. > I don't believe stating a disagreement is lecturing. My understanding is that we (or at least Eli and my response to him) are discussing concern for a hypothetical Elisp programmer, as Eli has (if I understood correctly) no problem understanding pcase. Maybe it would be more useful to say that LISP has at least 3 kinds of syntax - read syntax, special forms, and macros (forms defined by a function written in LISP itself). The difference between special forms and macros can largely be ignored, which is one of the special characteristics of LISP. The difference between read syntax and the latter two is more substantial. I think it's reasonable to expect a LISP programmer to recognize distinct text expressions for which the lisp "read" primitive produces identical S-exressions. Those differences cannot have anything to do with the LISP forms processed by the expander/evaluator. That being said, it wouldn't hurt to have a table exhaustively list all read syntax recognized by the reader in one place, for reference. It can be difficult to determine what a particular bit of LISP source code means when it contains infrequently used characters, since LISP is very permissive in the use of characters in symbols in general. I just don't think this dotted pair concern is a credible criticism of pcase. Maybe of a particular style preferences or idioms of different programmers, but it is orthogonal to pcase. Why would it only be confusing when used in a pcase form? pcase is not read-level syntax. Lynn --000000000000fc2cdf060b8aac29 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Dec 1, 2023, 10:20 PM Richard Stallman <rms@gnu.org> wrote:
=C2=A0 > > But a person who is just starting to look at this code, an= d reads that
=C2=A0 > > function first, is likely to be impeded in starting to rea= ch that sort
=C2=A0 > > of understanding.
=C2=A0 > >

=C2=A0 > I have to respectfully disagree - dotted pair notation is a pre= tty
=C2=A0 > fundamental part of LISP syntax, regardless of dialect.

That is true, but it is not pertinent to my finding that pcase code
confusing.=C2=A0 I know what dotted pairs mean, but I was not sure what
they meant in pcase patterns.

Likewise for Eli.=C2=A0 It is unkind and unhelpful to lecture him about
what dotted paris are.

I don't believe stating a disagreement is lecturi= ng.=C2=A0 My understanding is that we (or at least Eli and my response to h= im) are discussing concern for a hypothetical Elisp programmer, as Eli has = (if I understood correctly) no problem understanding pcase.

Maybe it would be more useful to say = that LISP has at least 3 kinds of syntax - read syntax, special forms, and = macros (forms defined by a function written in LISP itself).=C2=A0 The diff= erence between special forms and macros can largely be ignored, which is on= e of the special characteristics of LISP.=C2=A0 The difference between read= syntax and the latter two is more substantial.=C2=A0 I think it's reas= onable to expect a LISP programmer to recognize distinct text expressions f= or which the lisp "read" primitive produces identical S-exression= s.=C2=A0 Those differences cannot have anything to do with the LISP forms p= rocessed by the expander/evaluator.

That being said, it wouldn't hurt to have a table exhaustiv= ely list all read syntax recognized by the reader in one place, for referen= ce.=C2=A0 It can be difficult to determine what a particular bit of LISP so= urce code means when it contains infrequently used characters, since LISP i= s very permissive in the use of characters in symbols in general.

I just don't think this dotte= d pair concern is a credible criticism of pcase.=C2=A0 Maybe of a particula= r style preferences or idioms of different programmers, but it is orthogona= l to pcase.=C2=A0 Why would it only be confusing when used in a pcase form?= =C2=A0 pcase is not read-level syntax.

Lynn


=

--000000000000fc2cdf060b8aac29--