all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: "'Help-Gnu-Emacs (help-gnu-emacs@gnu.org)'" <help-gnu-emacs@gnu.org>
Subject: RE: [External] : Re: Emacs 30.0 warning from `cl-pushnew' and `memql'
Date: Thu, 29 Dec 2022 22:00:50 +0000	[thread overview]
Message-ID: <SJ0PR10MB5488DC25A22BC44E722CC339F3F39@SJ0PR10MB5488.namprd10.prod.outlook.com> (raw)
In-Reply-To: <jwvv8lurosn.fsf-monnier+emacs@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 4615 bytes --]

> > Oh, you meant that the simpler `case' syntax might
> > be harder for some of the people who are used to
> > the more complex syntax of `pcase', where you need
> > to quote symbols as values to be compared.
> 
> No, I mean that even for some people unfamiliar with `pcase` syntax, the
> `pcase` syntax is simpler (more natural?) than the cl-`case` syntax: the
> incorrect use of `quote` in `cl-case` predates the invention of `pcase`
> :-)

I think you'll need to explain your "incorrect use of
`quote' in `cl-case'".  There's no particular use of
`quote' or quoting in `case'.

Are you saying you think `case' should require users
to quote symbols to test for eqlity, i.e., that CL
should have defined `case' so that you need to use

(case FOO
  ('a             "AAA")
  (42             (value-for-42)) ; Or maybe use '42?
  (('c 'd 'e)     (value-for-C-D-or-E))
  (('f 'quote)    (value-for-F-or-QUOTE))
  ...)

instead of this?

(case FOO
  (a             "AAA")
  (42            (value-for-42))
  ((c d e)       (value-for-C-D-or-E))
  ((f quote)     (value-for-F-or-QUOTE))
  ...)

If so, why?

> >> > IOW, I don't argue that we shouldn't have `pcase'.
> >> > I don't see why we shouldn't also have `case'
> >> > (sans `cl-'), that's all.
> >> What's the benefit (other than having to learn 2
> >> subtly different things instead of just one)?
> > Simpler, for simple cases.
> 
> I don't think `case` is objectively simpler.

Please show us an example where `pcase' does
only what `case' does, but with simpler syntax.

> More specifically, I believe that if you're familiar
> with neither `cl-case` nor `pcase` syntax, it's not
> easier to learn the `case` syntax than the subset of
> `pcase` syntax which covers the functionality of `cl-case`.

1. It's easier to learn, if only because you
don't have to ALSO learn the non-`case' cases
that `pcase' syntax covers - including patterns
that both bind and match, etc.

You need to at least learn enough of that other
stuff to be able to _not_ fall into it when
you're trying to do just what simple `case'
does: test a value against some atomic values.

2. It's easier to use, for the same reason.

> It may even be objectively easier to learn the
> `pcase` syntax since it doesn't suffer from
> special cases like when you want to distinguish
> one of the `nil`, `t`, or `otherwise` values.

You pepper repeat "objectively", but isn't that
gratuitous?  Saying it's so doesn't make it so.
Show da codes, please.

`t' means the same thing as in `cond'.  Is it
really hard to grasp?  And to be "nicer", `case'
also gives you the synonym `otherwise', which
SHOUTS its meaning of "default", no?

And you can always just use a list for the test
values, including a singleton list.  Nothing
obliges one to take advantage of the shorthand
of using just b instead of (b). KISS: always a
list of things to match, or else `otherwise'
for no matches:

(case FOO
  ((a)           "AAA")
  ((nil)         "NIL")
  ((t)           "T")
  ((otherwise)   "Symbol `otherwise'")
  ((c d e)       "C, D, or E")
  ((f quote)     "F-or-QUOTE")
  (otherwise     "Anything else (default)"))

Sure, the simple, general syntax of using a list
of things to match means that () or nil as the
_list_ of values to match can never match (no
list elements to match).  Is that too complex?
It's something Lisp users are used to, no?  Even
novice Lisp users learn early on that nil/() is
both a list and a symbol.  `case' isn't the only
place where this needs to be understood.

It's common in Lisp programs to distinguish an
empty list of values from a single nil value
(whether viewed as symbol or empty list), by
wrapping the latter in a cons: (nil).

And always using an explicit list of things to
match (or else the atom `otherwise') makes it
very clear that () or nil as that list is useless
- no thing matches nothing.  If you really think
some users have trouble with the `case' syntax
then just tell 'em to always use a list of things
to match.

Which (`case' or `pcase') seems simpler might be
just a personal preference on each of our parts.

Lisp provides many ways to do the same thing,
including multiple control constructs (as I
mentioned, and about which you apparently had
nothing to say).

That `pcase' can do what `case' does isn't an
argument for not including `case' in Elisp.
Look at all of the `*-let' stuff that's been
added to Elisp over the last few years.  Really
needed?  Clearly someone thought that was all
useful for some users...

[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 16458 bytes --]

  reply	other threads:[~2022-12-29 22:00 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-26 20:38 Emacs 30.0 warning from `cl-pushnew' and `memql' Emanuel Berg
2022-12-27  6:56 ` Jean Louis
2022-12-27 10:28 ` Michael Heerdegen
2022-12-27 11:33   ` Emanuel Berg
2022-12-27 11:39   ` Emanuel Berg
2022-12-28  3:23     ` [External] : " Drew Adams
2022-12-28  4:23       ` Emanuel Berg
2022-12-29 22:27         ` Drew Adams
2022-12-30 22:27           ` Emanuel Berg
2022-12-30  6:30         ` tomas
2022-12-28  6:25     ` tomas
2022-12-28 11:59       ` Michael Heerdegen
2022-12-28 12:41         ` tomas
2022-12-28 12:45           ` Emanuel Berg
2022-12-28 13:19           ` Emanuel Berg
2022-12-28 14:54           ` Emanuel Berg
2022-12-29 22:31             ` Stefan Monnier via Users list for the GNU Emacs text editor
2023-01-08  4:18               ` Emanuel Berg
2023-01-08 18:54                 ` Andreas Eder
2022-12-28 17:57           ` [External] : " Drew Adams
2022-12-28 18:10             ` Stefan Monnier via Users list for the GNU Emacs text editor
2022-12-28 19:29               ` Emanuel Berg
2022-12-28 19:35               ` Drew Adams
2022-12-28 19:36               ` tomas
2022-12-28 19:24             ` Emanuel Berg
2022-12-28 17:54         ` Drew Adams
2022-12-28 18:05           ` Stefan Monnier via Users list for the GNU Emacs text editor
2022-12-28 19:35             ` Drew Adams
2022-12-29  3:34               ` Stefan Monnier via Users list for the GNU Emacs text editor
2022-12-29 19:06                 ` Drew Adams
2022-12-29 19:45                   ` Stefan Monnier via Users list for the GNU Emacs text editor
2022-12-29 22:00                     ` Drew Adams [this message]
2022-12-29 22:25                       ` Stefan Monnier via Users list for the GNU Emacs text editor
2022-12-30  7:29                         ` Drew Adams
2022-12-30 18:55                           ` Stefan Monnier via Users list for the GNU Emacs text editor
2022-12-30 22:55                             ` Drew Adams
2022-12-31  0:08                               ` Stefan Monnier via Users list for the GNU Emacs text editor
2022-12-31  2:45                                 ` Drew Adams
2022-12-31  4:53                                   ` Stefan Monnier via Users list for the GNU Emacs text editor
2022-12-28 19:21           ` Emanuel Berg
2022-12-28 20:24         ` Jean Louis
2022-12-28 20:56           ` Emanuel Berg
2022-12-28 21:24           ` [External] : " Drew Adams
2022-12-28 22:47             ` Jean Louis
2022-12-28 23:48               ` Emanuel Berg
2022-12-29  6:03               ` tomas
2022-12-29  6:59                 ` Emanuel Berg
2022-12-29  7:08                 ` Emanuel Berg
2022-12-29  7:19                 ` Emanuel Berg
2022-12-29 22:41                   ` Drew Adams
2022-12-30 23:03                     ` Emanuel Berg
2022-12-30  6:35                   ` tomas
2022-12-29  9:18                 ` Jean Louis
2022-12-29 10:04                   ` Emanuel Berg
2022-12-29 10:12                   ` tomas
2022-12-29 10:20                     ` Emanuel Berg
2022-12-29 10:26                     ` Emanuel Berg
2022-12-29 10:36                   ` Michael Heerdegen
2022-12-29 14:47                 ` Stefan Monnier via Users list for the GNU Emacs text editor
2022-12-29 10:39           ` Michael Heerdegen
2022-12-28 12:44       ` Emanuel Berg

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=SJ0PR10MB5488DC25A22BC44E722CC339F3F39@SJ0PR10MB5488.namprd10.prod.outlook.com \
    --to=drew.adams@oracle.com \
    --cc=help-gnu-emacs@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /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.