unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: Jean Louis <bugs@gnu.support>
To: Heime <heimeborgia@protonmail.com>
Cc: Stefan Monnier <monnier@iro.umontreal.ca>,
	Tomas Hlavaty <tom@logand.com>,
	help-gnu-emacs@gnu.org
Subject: Re: Advantage using mapc over dolist
Date: Tue, 3 Dec 2024 23:05:16 +0300	[thread overview]
Message-ID: <Z09kfIHFM1bg2uCO@lco2> (raw)
In-Reply-To: <7xlzeonoWSUauTrSplAmgZhQ82RWabA8HApJ7znvbfmBbIzxB_yA78vOqoht_Qs_VAABcnxMe4qCfV8X2yVAgovxFOcNLKrhGEIhvQsbol4=@protonmail.com>

* Heime via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2024-12-03 21:03]:
> > 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.

Statement alone doesn't create any difficulties unless in pcase that
user is reading-impaired or doesn't know English words.

Emacs Lisp is so large and with so many packages, so those users who
are on the level of decision making IMHO should have no problem
deciding pcase by pcase basis when to use one form or the other.

I understand that many things, such as using the Emacs Help system,
may be unclear to you. Naturally, we need to help each other to make
things clearer. However, as long as you are still struggling with
Emacs Help, how can I take your opinion on 'users should easily decide
when to use one form and when the other' seriously? They already can
and do so.

Some users will know how to use which form or the other, and some
users will not know, and some will not care less, like me.

> > , 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. 

I get that astonishment of you, but cl- prefix is basically
self-explanatory in Common Lisp documentation. It is made to be
compatible with the Common Lisp, so there is much about it somewhere
else.

> > 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.

Just to say something, neither I lost anything, nor I won anything.

Just in pcase there is still something to win, let me know?

> 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?

I know I can freely use cl-* one, so I just give my vote to make it well known.

There are scenarios where I don't want to use it, that is basically in
all scenarios within Emacs Lisp.

And when I program in Common Lisp, I do use it, I have bunch of it,
and use it every day, software I made for business over here, simply
works for years, so long that I even forgot how I did it.

> 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.

Common Lisp is not usual Lisp. Though by literal meaning sounds kind of similar. 
https://en.wikipedia.org/wiki/Common_Lisp

I am more and more using Emacs for business lead generation, it hangs
on the web server, and subscribes people, and handles double opt-in
subscriptions, it is all so much simpler for me to customize Emacs
file as user `www-data' and collect those opportunities. I am also
using Common Lisp for that, but I dislike complexities. It will be all
switched to simple Elisp.

Common Lisp is not Elisp, but there is no pcase against Common Lisp in
Emacs, it is welcome.

There are some CL functions that help users of Common Lisp to use them
within Emacs, those are cl- functions. 

So who is used to it, can use it.

It is though rarely used with Emacs configuration IMHO.

There is no discouragement, just that functions have different prefix.

Look this:

(defalias 'case 'cl-case)

case is an alias for ‘cl-case’.

(case EXPR (KEYLIST BODY...)...)

So just alias the function how you wish in your own package and just keep working without prefix if you wish.

-- 
Jean Louis



  reply	other threads:[~2024-12-03 20:05 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
2024-12-03 20:05           ` Jean Louis [this message]
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=Z09kfIHFM1bg2uCO@lco2 \
    --to=bugs@gnu.support \
    --cc=heimeborgia@protonmail.com \
    --cc=help-gnu-emacs@gnu.org \
    --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).