unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: Heime via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Tomas Hlavaty <tom@logand.com>, help-gnu-emacs@gnu.org
Subject: Re: Advantage using mapc over dolist
Date: Tue, 03 Dec 2024 18:01:42 +0000	[thread overview]
Message-ID: <7xlzeonoWSUauTrSplAmgZhQ82RWabA8HApJ7znvbfmBbIzxB_yA78vOqoht_Qs_VAABcnxMe4qCfV8X2yVAgovxFOcNLKrhGEIhvQsbol4=@protonmail.com> (raw)
In-Reply-To: <jwviks07mn1.fsf-monnier+emacs@gnu.org>


On Wednesday, December 4th, 2024 at 4:47 AM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> > I respect your preference and understand that you as pcase author would
> > prefer it everywhere. But whoever renamed case and ecase did not
> > respect other peoples preferences and people are now forced to use that
> > pcase monstrosity even in very simple cases.
> 
> 
> I'm also the renamer of `case/ecase`, yes. 🙂
> 
> This was not done to discourage people's use of it, actually the
> reverse. Yes, I know it sounds counter intuitive

Your statement that it is counter intuitive does actually result in difficulties
to users.  Instead, things should be clear, so users can easily decide when to 
use one form and when the other, or if there is no difference alone.

> , so let me explain:
> Richard was strongly opposed to the use of the CL package because of its
> "stepping" all over the ELisp namespace. For years, this manifested
> itself in the fact that use of CL within Emacs's own code was generally
> shunned and tolerated only with (eval-when-compile (require 'cl)),
> meaning that you could use CL only when it could be compiled away during
> byte-compilation (by macro-expansion and/or inlining). So you could use
> `ecase` but not `some`.

This discouragement seems to have remained present.  Users looking at the cl-*
also wonder in what situations would they use them and when to use the elisp
ones.  One cannot find a clear discussion about this in the manual, in a way
that a user can make the suitable decision about which to use. 

> While some people were happy because they consider that ELisp is better
> off without those Common Lisp constructs, many others were annoyed, and
> it imposed obstacles to the inclusion of some packages into Emacs.
> 
> Finally in Emacs-24.3, we reached a compromise which was to introduce
> CL-Lib, which is like CL except all the functions/macros are prefixed
> with "cl-". By its nature as a compromise, everyone both lost and won
> at the same time.

The question is whether people can use the cl-* ones freely or not.  Are 
there scenarios when you don't want to use them but use the elisp ones instead?

One thing I still have difficulty about is how the usual  lisp is discouraged
when elisp is supposedly normal lisp for use with emacs configuration. But
has evolved into something else.

 
> Note that if you really really hate using these extra three letters, you
> can still (require 'cl). It's deprecated and may be removed from Emacs in
> some future release, but it's a very simple library so you can keep your
> own copy (and we may even put it up on GNU ELPA anyway).
> 
> 
> Stefan



  reply	other threads:[~2024-12-03 18:01 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-01 23:31 Advantage using mapc over dolist Heime via Users list for the GNU Emacs text editor
2024-12-02  6:26 ` Tomas Hlavaty
2024-12-02 18:30   ` Heime via Users list for the GNU Emacs text editor
2024-12-02 20:41     ` Tomas Hlavaty
2024-12-02 20:50       ` Jean Louis
2024-12-02 21:21         ` Tomas Hlavaty
2024-12-02 21:41           ` Heime via Users list for the GNU Emacs text editor
2024-12-03  6:13           ` Jean Louis
2024-12-03  7:36             ` Tomas Hlavaty
2024-12-03 19:24               ` Jean Louis
2024-12-03 20:04                 ` Tomas Hlavaty
2024-12-03 20:09                   ` Jean Louis
2024-12-03 20:12                   ` Heime via Users list for the GNU Emacs text editor
2024-12-03 20:24                     ` Jean Louis
2024-12-02 20:56       ` Heime via Users list for the GNU Emacs text editor
2024-12-03 19:26         ` Jean Louis
2024-12-03 19:39           ` Heime via Users list for the GNU Emacs text editor
2024-12-03 14:11   ` Stefan Monnier via Users list for the GNU Emacs text editor
2024-12-03 14:48     ` Tomas Hlavaty
2024-12-03 16:31       ` Stefan Monnier
2024-12-03 17:00         ` Alfred M. Szmidt
2024-12-03 17:24           ` Stefan Monnier
2024-12-03 19:27             ` Tomas Hlavaty
2024-12-03 19:35               ` Heime via Users list for the GNU Emacs text editor
2024-12-03 14:59     ` Tomas Hlavaty
2024-12-03 15:40       ` Tomas Hlavaty
2024-12-03 15:57         ` Tomas Hlavaty
2024-12-03 17:11           ` Eli Zaretskii
2024-12-03 17:33             ` Tomas Hlavaty
2024-12-03 17:40               ` Eli Zaretskii
2024-12-03 17:55                 ` Tomas Hlavaty
2024-12-03 18:05                   ` Heime via Users list for the GNU Emacs text editor
2024-12-03 18:57                     ` Alfred M. Szmidt
2024-12-03 19:06                       ` Heime via Users list for the GNU Emacs text editor
2024-12-03 20:15                       ` Tomas Hlavaty
2024-12-04  5:37                         ` Alfred M. Szmidt
2024-12-03 19:42         ` Jean Louis
2024-12-03 19:54           ` Heime via Users list for the GNU Emacs text editor
2024-12-03 20:11             ` Jean Louis
2024-12-03 16:47       ` Stefan Monnier
2024-12-03 18:01         ` Heime via Users list for the GNU Emacs text editor [this message]
2024-12-03 20:05           ` Jean Louis
2024-12-03 20:35         ` Tomas Hlavaty
2024-12-03 23:29           ` Stefan Monnier
2024-12-04  0:57             ` Heime via Users list for the GNU Emacs text editor
2024-12-04  2:20               ` Stefan Monnier via Users list for the GNU Emacs text editor
2024-12-03 19:38       ` Jean Louis
2024-12-04  4:56       ` Michael Heerdegen via Users list for the GNU Emacs text editor
2024-12-02  6:59 ` Tassilo Horn
2024-12-02 10:12   ` Michael Heerdegen via Users list for the GNU Emacs text editor
2024-12-02 17:03     ` Heime via Users list for the GNU Emacs text editor
2024-12-02 18:51       ` Tomas Hlavaty
2024-12-02 20:17         ` Heime via Users list for the GNU Emacs text editor
2024-12-02 21:07           ` Tomas Hlavaty
2024-12-03 13:19             ` Tomas Hlavaty
2024-12-02 21:15         ` [External] : " Drew Adams
2024-12-02 21:58           ` Tomas Hlavaty
2024-12-02 22:42             ` Drew Adams
2024-12-03  5:49               ` Tomas Hlavaty
2024-12-03 20:08                 ` Lazy functional programming [was: Advantage using mapc over dolist] Drew Adams
2024-12-03 21:17                   ` Tomas Hlavaty
2024-12-04  4:33         ` Advantage using mapc over dolist Michael Heerdegen

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='7xlzeonoWSUauTrSplAmgZhQ82RWabA8HApJ7znvbfmBbIzxB_yA78vOqoht_Qs_VAABcnxMe4qCfV8X2yVAgovxFOcNLKrhGEIhvQsbol4=@protonmail.com' \
    --to=help-gnu-emacs@gnu.org \
    --cc=heimeborgia@protonmail.com \
    --cc=monnier@iro.umontreal.ca \
    --cc=tom@logand.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.
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).