all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Barry Fishman <barry@ecubist.org>,
	"emacs-devel@gnu.org" <emacs-devel@gnu.org>
Subject: RE: [External] : Re: cond* vs pcase
Date: Wed, 7 Feb 2024 17:22:49 +0000	[thread overview]
Message-ID: <SJ0PR10MB548824E2C411BC4A476667BDF3452@SJ0PR10MB5488.namprd10.prod.outlook.com> (raw)
In-Reply-To: <7ny1bw71v3.fsf@ecube.ecubist.org>

> What bothers me the most about it is that rather [than]
> breaking these problems into simpler operations and
> providing a means of composing them to handle more
> complex situation, the pcase/cond*/loop constructs
> mix them all in to a single form.
> 
> This is defended by saying that it helps move some of
> the complexity from the user to the macro processor.
> But like the current generation of 'generative AI'
> solutions to problems, it seems to hide the complexity
> in a way that subtle errors get hard to discover.  New
> coders end up spending their time copying code fragments
> rather than understanding what is going on.

Indeed.  (And maybe not just new coders.)

But there's room (a "case" to be made) for both:

1. Specific simple, combinable constructs:
   `let', `case', `cond', `if', `when', `or',
   `while', `dolist', `catch',...

2. More generic constructs that combine binding,
   destructuring, and conditional/control:
   `pcase', `cl-loop',...

What there's not a great "case" for is _always_
using #2, just because you can.  You can, but
there can be a cost to your readers.

Occam's razor says _not to multiply things
unnecessarily_.

In this context, does that mean have just one,
generic, complex construct (don't multiply the
number of constructs)?  Or does it mean use the
simplest, clearest construct in each particular
code context?

Does it add unnecessary noise to have a `case'
conditional, in addition to `pcase'?  Or does
it add unnecessary noise to always use `pcase',
including in contexts where it's overkill?

Whether it's `pcase' or `cond*', combining
binding, destructuring, and conditional control
is a mouthful.  It can be powerful, but it can
also be awful.  And even when used correctly,
it can be overkill.

Should we purge Lisp of `let', `cond', `dolist',
and the rest, just because we can do everything
with `pcase' and `cl-loop'?  Silly question, no?

Well that's really the question here.  Let's add
`case' to Elisp (proper).  And let's give it an
optional TEST argument.



      reply	other threads:[~2024-02-07 17:22 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-05 14:30 cond* vs pcase Arthur Miller
2024-02-05 15:13 ` Eli Zaretskii
2024-02-05 16:06 ` Alfred M. Szmidt
2024-02-05 18:39   ` Philip Kaludercic
2024-02-06 12:30     ` Arthur Miller
2024-02-06 16:17     ` Alfred M. Szmidt
2024-02-06 16:35       ` [External] : " Drew Adams
2024-02-06 16:50       ` Philip Kaludercic
2024-02-06 17:27         ` Alfred M. Szmidt
2024-02-06 18:57           ` Philip Kaludercic
2024-02-06 19:04             ` Alfred M. Szmidt
2024-02-06 19:39               ` Philip Kaludercic
2024-02-06 23:17                 ` [External] : " Drew Adams
2024-02-06 19:12             ` Drew Adams
2024-02-06 20:08               ` Adam Porter
2024-02-06 23:32                 ` Drew Adams
2024-02-07 13:14                   ` Arthur Miller
2024-02-07 13:43                     ` Po Lu
2024-02-07 17:09                       ` Drew Adams
2024-02-07 17:44                       ` Tomas Hlavaty
2024-02-09  3:52                         ` Richard Stallman
2024-02-07 18:00                       ` Arthur Miller
2024-02-07 18:22                         ` Alfred M. Szmidt
2024-02-08  1:55                           ` Po Lu
2024-02-08  2:49                             ` Philip Kaludercic
2024-02-08  3:36                               ` Po Lu
2024-02-08  7:04                             ` Eli Zaretskii
2024-02-08 17:01                               ` Alfred M. Szmidt
2024-02-08 17:01                             ` Alfred M. Szmidt
2024-02-09  1:30                               ` Po Lu
2024-02-08  5:01                         ` Po Lu
     [not found]                           ` <DU2PR02MB10109B7AC39F995BFE266EF5396442@DU2PR02MB10109.eurprd02.prod.outlook.com>
2024-02-08  7:36                             ` Sv: " Arthur Miller
2024-02-12 21:39                       ` Stefan Monnier via Emacs development discussions.
2024-02-07 17:14                     ` Drew Adams
2024-02-07  5:32             ` Yuri Khan
2024-02-07 12:43               ` Arthur Miller
2024-02-07 17:41                 ` Alfred M. Szmidt
2024-02-07 18:36                   ` Arthur Miller
2024-02-07 19:12                     ` Alfred M. Szmidt
2024-02-07 21:20                       ` Arthur Miller
2024-02-06 17:29         ` [External] : " Drew Adams
2024-02-06 17:41           ` Alfred M. Szmidt
2024-02-06 17:50         ` Thierry Volpiatto
2024-02-06 19:04           ` Alfred M. Szmidt
2024-02-07 15:03           ` Barry Fishman
2024-02-07 17:22             ` Drew Adams [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=SJ0PR10MB548824E2C411BC4A476667BDF3452@SJ0PR10MB5488.namprd10.prod.outlook.com \
    --to=drew.adams@oracle.com \
    --cc=barry@ecubist.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.