From: Drew Adams <drew.adams@oracle.com>
To: 31311@debbugs.gnu.org
Cc: Noam Postavsky <npostavs@gmail.com>
Subject: bug#31311: 27.0; doc of `pcase'
Date: Sat, 26 May 2018 08:26:02 -0700 (PDT) [thread overview]
Message-ID: <33cb1c7a-38a2-4d74-a266-51be5b636552@default> (raw)
In-Reply-To: <87fu2e23jy.fsf@gnuvola.org>
> The manual should refer to `cl-case', not `case'.
I disagree. My (unsolicited) 2 cents:
`case' is aliased to `cl-case', IF you load `cl.el' at
byte-compile time. It has always been so, and it should
remain so. Or the other way around: we should instead
alias `cl-case' to `case'.
Encouraging everyone to instead load `cl-lib.el' does _not_
provide `case'. If `cl-lib.el' is to be the way to go then
it should itself provide the alias.
Dunno whether this lack was an oversight or deliberate, but
it is a step backward. We now (rightfully) encourage users
to load `cl-lib.el' instead of `cl.el', but we no longer
bother to encourage loading `cl.el' at compile time to pick
up macros.
But no one should even need to load `cl-lib.el' (or `cl.el'
at compile time). Emacs should itself have `case', prominently
and first class.
And it is fine if the Emacs `case' is also the Common Lisp
`case', or close to it. The same should be true elsewhere:
Emacs appropriating Common Lisp constructs is fine and dandy.
But yes, of course, as long as `case' (aka `cl-case') is not
*exactly* the same as the Common Lisp `case' the two should
remain aliased, and any differences from Common Lisp should
be documented.
But users should first and foremost see `case', not `cl-case'.
It should be as prominent as `cond' and `if', `when', and
`unless' - ALL of which also exist in Common Lisp. We don't
call them `cl-cond', `cl-if', `cl-when', and `cl-unless'!
And rightfully so.
Preload the `cl-case' definition in Emacs, call it `case',
and alias `cl-case' to it.
There is no reason to force or encourage people to use
`cl-case' instead of `case'. The opposite is true - they
should be encouraged to use `case', not `cl-case'. Emacs
deserves `case', and it has `case' - you just have to know
about jumping through a hoop to reveal it.
[We even had the extreme position a few years ago that an
eager-beaver mmaintainer forced names like `cl-caddr' on
Emacs. Fortunately, that craziness was eventually rescinded.
http://lists.gnu.org/archive/html/emacs-devel/2016-02/msg01394.html
]
_______
On a related subject, `pcase', and especially its derivatives,
should be renamed. These things are not (are no longer) about
a kind of `case'.
Their names should share a common root, yes. But it should not
be just `p', and it should definitely not be `case'. Their
names should have a root that suggests pattern matching and, at
least in some cases, binding/destructuring. (Start a contest to
find a good root name. ;-))
> I did ‘s/case/cl-&/g’ in commit 468e82790f1
Too bad. That's a step backward, not forward, IMHO.
> Many computer languages have an intrinsic case-ish construct, so
> it was a bit surprising for me to learn that ‘case’ in Emacs
> Lisp is actually ‘cl-case’, which has a second-class citizen
> feel.
Exactly. And there is no need for that second-class status.
And it is _new_. In the past everyone just used `case' in
Emacs. And they still can, the same way, by loading `cl.el'
at byte-compile time, to pick up the macro. They should not
need to do that.
> In using ‘cl-case’ as one of the conceptual parents of ‘pcase’,
But it's not, really. Maybe "parent" in the sense of design
ancestor, but not "parent" in the sense of current derivation
or resemblance.
> - Build on "expectatious programmer" mindset. Programmers new
> to Emacs Lisp might feel that same surprise i felt and do what
> i did: reach for ‘cl-case’ immediately, making it a habit to
> such an extent as to consider it intrinsic (thus, familiar).
Yes.
next prev parent reply other threads:[~2018-05-26 15:26 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-29 16:03 bug#31311: 27.0; doc of `pcase' Drew Adams
2018-04-29 16:39 ` Eli Zaretskii
2018-04-29 18:31 ` Michael Heerdegen
2018-04-29 18:45 ` Eli Zaretskii
2018-04-29 20:05 ` Michael Heerdegen
2018-04-30 2:36 ` Eli Zaretskii
2018-04-30 11:20 ` Noam Postavsky
2018-04-30 13:35 ` Thien-Thi Nguyen
2018-04-30 16:58 ` Drew Adams
2018-04-30 18:04 ` Michael Heerdegen
2018-05-01 9:41 ` Thien-Thi Nguyen
2018-04-30 19:31 ` Eli Zaretskii
2018-05-12 11:18 ` Thien-Thi Nguyen
2018-05-12 13:54 ` Michael Heerdegen
2018-05-15 14:24 ` Thien-Thi Nguyen
2018-05-15 15:16 ` Michael Heerdegen
2018-05-16 10:43 ` Thien-Thi Nguyen
2018-05-16 15:18 ` Michael Heerdegen
2018-05-20 18:59 ` Thien-Thi Nguyen
2018-05-23 13:55 ` Drew Adams
2018-05-23 15:42 ` Eli Zaretskii
2018-05-23 15:28 ` Eli Zaretskii
2018-05-23 19:16 ` Thien-Thi Nguyen
2018-05-24 16:23 ` Eli Zaretskii
2018-05-26 7:58 ` Thien-Thi Nguyen
2018-05-24 23:13 ` Noam Postavsky
2018-05-26 9:01 ` Thien-Thi Nguyen
2018-05-26 15:26 ` Drew Adams [this message]
2018-05-27 8:22 ` Thien-Thi Nguyen
2018-05-27 8:41 ` Thien-Thi Nguyen
2018-05-27 13:31 ` Drew Adams
2018-05-27 14:12 ` Noam Postavsky
2018-05-27 16:16 ` Eli Zaretskii
2018-05-27 16:26 ` Eli Zaretskii
2018-05-27 16:32 ` Andreas Schwab
2018-05-27 17:30 ` Eli Zaretskii
2018-05-27 17:45 ` Andreas Schwab
2018-05-27 17:42 ` Thien-Thi Nguyen
2018-05-28 7:25 ` Nicolas Petton
2018-05-28 7:33 ` Nicolas Petton
2018-05-28 8:27 ` Eli Zaretskii
2018-05-28 9:32 ` Nicolas Petton
2018-05-12 13:56 ` Noam Postavsky
2018-05-15 14:37 ` Thien-Thi Nguyen
2019-08-25 12:56 ` Michael Heerdegen
2018-04-30 14:28 ` Eli Zaretskii
2018-04-29 22:59 ` Drew Adams
2018-04-29 23:16 ` Noam Postavsky
2018-04-29 23:28 ` Drew Adams
2018-04-30 0:29 ` Michael Heerdegen
2018-04-30 2:47 ` Drew Adams
2018-04-30 7:48 ` Thien-Thi Nguyen
2018-05-21 17:04 ` Thien-Thi Nguyen
2022-04-29 13:48 ` Lars Ingebrigtsen
2022-04-29 14:39 ` Drew Adams
[not found] <<b5d5bbd5-f90c-4836-9307-7a74ad0b2320@default>
[not found] ` <<83wowqrmp8.fsf@gnu.org>
2018-04-29 17:02 ` Drew Adams
2018-04-29 17:16 ` Eli Zaretskii
2018-04-29 18:38 ` Michael Heerdegen
2018-04-29 19:43 ` Drew Adams
2018-04-29 20:00 ` Michael Heerdegen
[not found] <<<b5d5bbd5-f90c-4836-9307-7a74ad0b2320@default>
[not found] ` <<<83wowqrmp8.fsf@gnu.org>
[not found] ` <<9cd18e10-8f14-4a49-a3a4-ed9d50afe860@default>
[not found] ` <<83sh7erl01.fsf@gnu.org>
2018-04-29 17:26 ` Drew Adams
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=33cb1c7a-38a2-4d74-a266-51be5b636552@default \
--to=drew.adams@oracle.com \
--cc=31311@debbugs.gnu.org \
--cc=npostavs@gmail.com \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).