Advantage using mapc over dolist

Advantage using mapc over dolist

[Heime via Users list for the GNU Emacs text editor]

Is there any advantage using mapc over dolist when looping through
a list passed as argument to a function?

(defun marsi (actm-seqr)
  (mapc (lambda (actm)
          (pcase actm
           ('armg (do-this))
           ('go (do-that))))
         actm-seqr))

(defun marsi (actm-seqr)
  (dolist (actm actm-seqr)
    (pcase actm
      ('armg (do-this))
      ('go (do-that)))))

Re: Advantage using mapc over dolist

[Tomas Hlavaty]

On Sun 01 Dec 2024 at 23:31, Heime via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> wrote:
> Is there any advantage using mapc over dolist when looping through
> a list passed as argument to a function?

no

in your example, dolist would be nicer

>           (pcase actm
>            ('armg (do-this))
>            ('go (do-that))))

this does not justify pcase, use ecase or case instead

Re: Advantage using mapc over dolist

[Heime via Users list for the GNU Emacs text editor]

On Monday, December 2nd, 2024 at 6:26 PM, Tomas Hlavaty <tom@logand.com> wrote:

> On Sun 01 Dec 2024 at 23:31, Heime via Users list for the GNU Emacs text editor help-gnu-emacs@gnu.org wrote:
> 
> > Is there any advantage using mapc over dolist when looping through
> > a list passed as argument to a function?
> 
> 
> no
> 
> in your example, dolist would be nicer
> 
> > (pcase actm
> > ('armg (do-this))
> > ('go (do-that))))
> 
> 
> this does not justify pcase, use ecase or case instead


I cannot see documentation for ecase or case!

Re: Advantage using mapc over dolist

[Tomas Hlavaty]

On Mon 02 Dec 2024 at 18:30, Heime <heimeborgia@protonmail.com> wrote:
> I cannot see documentation for ecase or case!

hmm, somebody renamed it to cl-ecase and cl-case
similar to flet -> cl-flet and labels -> cl-labels
what a shame

Re: Advantage using mapc over dolist

[Jean Louis]

* Tomas Hlavaty <tom@logand.com> [2024-12-02 23:42]:
> On Mon 02 Dec 2024 at 18:30, Heime <heimeborgia@protonmail.com> wrote:
> > I cannot see documentation for ecase or case!
> 
> hmm, somebody renamed it to cl-ecase and cl-case
> similar to flet -> cl-flet and labels -> cl-labels
> what a shame

I find it liberating.

-- 
Jean Louis

Re: Advantage using mapc over dolist

[Tomas Hlavaty]

On Mon 02 Dec 2024 at 23:50, Jean Louis <bugs@gnu.support> wrote:
>> hmm, somebody renamed it to cl-ecase and cl-case
>> similar to flet -> cl-flet and labels -> cl-labels
>> what a shame
>
> I find it liberating.

What do you mean?
Could you explain that?

Emacs is switching to lexical scope and degraded two of the most lexical
scope related things to secodary citizens.

Re: Advantage using mapc over dolist

[Heime via Users list for the GNU Emacs text editor]

Sent with Proton Mail secure email.

On Tuesday, December 3rd, 2024 at 9:21 AM, Tomas Hlavaty <tom@logand.com> wrote:

> On Mon 02 Dec 2024 at 23:50, Jean Louis bugs@gnu.support wrote:
> 
> > > hmm, somebody renamed it to cl-ecase and cl-case
> > > similar to flet -> cl-flet and labels -> cl-labels
> > > what a shame
> > 
> > I find it liberating.
> 
> 
> What do you mean?
> Could you explain that?
> 
> Emacs is switching to lexical scope and degraded two of the most lexical
> scope related things to secodary citizens.

Meaning that common lisp is a secondary citizen within the emacs environment.  
Right?

Re: Advantage using mapc over dolist

[Jean Louis]

* Tomas Hlavaty <tom@logand.com> [2024-12-03 00:21]:
> On Mon 02 Dec 2024 at 23:50, Jean Louis <bugs@gnu.support> wrote:
> >> hmm, somebody renamed it to cl-ecase and cl-case
> >> similar to flet -> cl-flet and labels -> cl-labels
> >> what a shame
> >
> > I find it liberating.
> 
> What do you mean?
> Could you explain that?
> 
> Emacs is switching to lexical scope and degraded two of the most lexical
> scope related things to secodary citizens.

I am an Emacs Lisp programmer, and all Common Lisp functions prefixed with `cl-` I find liberating in the sense that personally within Emacs Lisp I do not like mixing it because it is not Common Lisp. All my software was first in Common Lisp, I know it and use it every day, I am a heavy user of my own Common Lisp. But within Emacs, I like using Emacs Lisp pure—it is a personal choice.

-- 
Jean Louis

Re: Advantage using mapc over dolist

[Tomas Hlavaty]

On Tue 03 Dec 2024 at 09:13, Jean Louis <bugs@gnu.support> wrote:
> * Tomas Hlavaty <tom@logand.com> [2024-12-03 00:21]:
>> On Mon 02 Dec 2024 at 23:50, Jean Louis <bugs@gnu.support> wrote:
>> >> hmm, somebody renamed it to cl-ecase and cl-case
>> >> similar to flet -> cl-flet and labels -> cl-labels
>> >> what a shame
>> >
>> > I find it liberating.
>> 
>> What do you mean?
>> Could you explain that?
>> 
>> Emacs is switching to lexical scope and degraded two of the most lexical
>> scope related things to secodary citizens.
>
> I am an Emacs Lisp programmer, and all Common Lisp functions prefixed with `cl-` I find liberating in the sense that personally within Emacs Lisp I do not like mixing it because it is not Common Lisp. All my software was first in Common Lisp, I know it and use it every day, I am a heavy user of my own Common Lisp. But within Emacs, I like using Emacs Lisp pure—it is a personal choice.

I do not understand this explanation.  It feels like renaming car and
cdr because it feels liberating.  Beginners have been nagging about this
for maybe 60 years already.  iirc flet, labels, case, ecase predate
Common Lisp and were present in ancient Emacs Lisp too (but I am not a
Lisp historian).  Moving to lexical scoping and at the same time
incompatibly renaming those fundamental lisp forms seems silly to me.
They do not even have keyword arglist.  Anytime I process complex data
recursively, I reach for labels.  There does not seem to be an
alternative, does it?  That means infecting my code with cl-lib
silliness.  And how infecting Emacs with pcase monstrosity feels
liberating compared to simple case and ecase?

Re: Advantage using mapc over dolist

[Jean Louis]

* Tomas Hlavaty <tom@logand.com> [2024-12-03 10:36]:
> On Tue 03 Dec 2024 at 09:13, Jean Louis <bugs@gnu.support> wrote:
> > * Tomas Hlavaty <tom@logand.com> [2024-12-03 00:21]:
> >> On Mon 02 Dec 2024 at 23:50, Jean Louis <bugs@gnu.support> wrote:
> >> >> hmm, somebody renamed it to cl-ecase and cl-case
> >> >> similar to flet -> cl-flet and labels -> cl-labels
> >> >> what a shame
> >> >
> >> > I find it liberating.
> >> 
> >> What do you mean?
> >> Could you explain that?
> >> 
> >> Emacs is switching to lexical scope and degraded two of the most lexical
> >> scope related things to secodary citizens.
> >
> > I am an Emacs Lisp programmer, and all Common Lisp functions prefixed with `cl-` I find liberating in the sense that personally within Emacs Lisp I do not like mixing it because it is not Common Lisp. All my software was first in Common Lisp, I know it and use it every day, I am a heavy user of my own Common Lisp. But within Emacs, I like using Emacs Lisp pure—it is a personal choice.

But Tomas, I mentioned nothing about pcase. I said cl- namespace being
separate feels liberating to me as my personal choice. If you wish to
use those commands without cl-prefix, there is solution that Stefan
wrote in recent email.

> I do not understand this explanation.  It feels like renaming car and
> cdr because it feels liberating.

It can be. Lisp is all about making it right for you. I actually like
that `first' is now `cl-first', but if I wish to use it, I can simply
alias it.

You could make list and alias functions and you are fine.

> Beginners have been nagging about this for maybe 60 years already.

Congrats!

> iirc flet, labels, case, ecase predate Common Lisp and were present
> in ancient Emacs Lisp too (but I am not a Lisp historian).  Moving
> to lexical scoping and at the same time incompatibly renaming those
> fundamental lisp forms seems silly to me.

I don't know lexical, but what I know is that I have no problems with
lexical, and those global packages still work. I have one of them, I
keep it global, and I am fine with it all. 

> They do not even have keyword arglist.  Anytime I process complex
> data recursively, I reach for labels.  There does not seem to be an
> alternative, does it? 

I have no idea about it, let me see what AI says:

In **Common Lisp**, `labels` is a powerful macro used for defining **local functions**, including those that are **mutually recursive**. This is particularly useful when working with **recursive algorithms** or **complex data processing**, as it allows you to encapsulate helper functions within the scope of another function without polluting the global namespace.

### **Common Lisp `labels`**

#### **Usage Example:**

```lisp
(defun compute-factorials (numbers)
  (labels ((factorial (n)
             (if (<= n 1)
                 1
                 (* n (factorial (1- n))))))
    (mapcar #'factorial numbers)))
```

In this example:

- **`labels`** defines a local function `factorial` within `compute-factorials`.
- The `factorial` function can call itself recursively.
- This setup keeps the `factorial` function **encapsulated**, preventing it from being accessible outside `compute-factorials`.

### **Emacs Lisp and `labels`**

While **Emacs Lisp** does not natively support `labels` as Common Lisp does, it provides similar functionality through the **Common Lisp extensions** available in Emacs via the `cl-lib` package. Specifically, you can use `cl-labels` to achieve the same effect.

#### **Using `cl-labels` in Emacs Lisp:**

1. **Enable `cl-lib`:**

   Make sure to require the `cl-lib` package at the beginning of your Emacs Lisp file or session:

   ```elisp
   (require 'cl-lib)
   ```

2. **Define Local Functions with `cl-labels`:**

   ```elisp
   (cl-labels ((factorial (n)
                  (if (<= n 1)
                      1
                    (* n (factorial (1- n))))))
     (mapcar #'factorial '(1 2 3 4 5)))
   ```

   In this example:

   - **`cl-labels`** is used to define a local `factorial` function within the scope.
   - The `factorial` function can recursively call itself.
   - The local function remains **private** to the `cl-labels` block.

### **Alternatives to `labels`**

If you prefer not to use `cl-labels`, there are alternative approaches to handle recursion and complex data processing in both Common Lisp and Emacs Lisp:

1. **Global Function Definitions:**

   Define helper functions globally. This is straightforward but can lead to namespace pollution.

   ```lisp
   (defun global-factorial (n)
     (if (<= n 1)
         1
         (* n (global-factorial (1- n)))))
   
   (defun compute-factorials (numbers)
     (mapcar #'global-factorial numbers))
   ```

2. **Anonymous Functions and Closures:**

   Use lambda expressions and closures to encapsulate functionality.

   ```lisp
   (defun compute-factorials (numbers)
     (let ((factorial (lambda (n)
                        (if (<= n 1)
                            1
                          (* n (funcall factorial (1- n)))))))
       (mapcar factorial numbers)))
   ```

   *Note: In Emacs Lisp, this approach can be more cumbersome due to the way closures handle recursion.*

3. **Higher-Order Functions:**

   Utilize higher-order functions to pass recursive behavior as arguments.

   ```lisp
   (defun compute-factorials (numbers)
     (mapcar (lambda (n)
               (labels ((factorial (n)
                          (if (<= n 1)
                              1
                            (* n (factorial (1- n))))))
                 (factorial n)))
             numbers))
   ```

### **Conclusion**

- **`labels` in Common Lisp**: Essential for defining local, potentially recursive functions within a function's scope.
- **`cl-labels` in Emacs Lisp**: Provides similar functionality through the `cl-lib` package, allowing local and recursive function definitions.
- **Alternatives**: While global definitions and other methods exist, `labels` and `cl-labels` offer a clean and encapsulated way to handle recursion and complex data processing.

**Therefore, when dealing with recursive processing in Common Lisp or Emacs Lisp, `labels` (or `cl-labels` in Emacs) remains one of the most effective and idiomatic solutions.**

---

So I would say, I would not get frustrated, rather just make an alias
for me and use `labels' wherever I wish and want.

> That means infecting my code with cl-lib silliness.

I understand your feelings, but same could be said when you use any
Emacs package, the namespaces are not same as in Common Lisp, so it is
to be swallowed. Today is cl- and tomorrow is something else like lc-
or rcd- or rms- whatever. 

> And how infecting Emacs with pcase monstrosity feels liberating
> compared to simple case and ecase?

I have no single use of `pcase' but I know what it does. I like so much `cond'.

-- 
Jean Louis

Re: Advantage using mapc over dolist

[Tomas Hlavaty]

On Tue 03 Dec 2024 at 22:24, Jean Louis <bugs@gnu.support> wrote:
>> > I am an Emacs Lisp programmer, and all Common Lisp functions
>> > prefixed with `cl-` I find liberating in the sense that personally
>> > within Emacs Lisp I do not like mixing it because it is not Common Lisp.

Maybe the issue is that too many things were degraded into cl-*.
And now very complex bad ideas are pushed as replacement fix.

>> > But within Emacs, I like using Emacs Lisp pure

Not sure what does "Emacs Lisp pure" mean.
Does it mean "Whatever comes with Emacs except cl-* stuff."?

"Emacs Lisp pure" had CASE and ECASE in 1993 (conversion to RCS
according to git) until 2012 iirc.

> But Tomas, I mentioned nothing about pcase. I said cl- namespace being
> separate feels liberating to me as my personal choice. If you wish to
> use those commands without cl-prefix, there is solution that Stefan
> wrote in recent email.

Bad workarounds do not fill me with joy.

>> Anytime I process complex
>> data recursively, I reach for labels.  There does not seem to be an
>> alternative, does it? 
>
> I have no idea about it, let me see what AI says:

That AI is not good enough.
The examples are too trivial to justify labels.

This function has a structure which does justify labels:

(defun parse-rss (dom)
  (let (z)
    (cl-labels ((link (x)
                  (when (consp x)
                    (cl-case (car x)
                      (link (push (caddr x) z))
                      (t (mapc #'link (cddr x))))))
                (rec (x)
                  (when (consp x)
                    (cl-case (car x)
                      (item (link x))
                      (t (mapc #'rec (cddr x)))))))
      (rec dom))
    (nreverse z)))

> So I would say, I would not get frustrated, rather just make an alias
> for me and use `labels' wherever I wish and want.

This does not address the problem.

In my Elisp code, I simply require cl-lib, add those cl- prefixes where
needed and live with the result.

However, here simple and likely pre-CL functions and macros are degraded
to cl-*, people are discouraged from using cl-* and encouraged to use
something even more bonkers than cl-* ;-)

Re: Advantage using mapc over dolist

[Jean Louis]

* Tomas Hlavaty <tom@logand.com> [2024-12-03 23:04]:
> On Tue 03 Dec 2024 at 22:24, Jean Louis <bugs@gnu.support> wrote:
> >> > I am an Emacs Lisp programmer, and all Common Lisp functions
> >> > prefixed with `cl-` I find liberating in the sense that personally
> >> > within Emacs Lisp I do not like mixing it because it is not Common Lisp.
> 
> Maybe the issue is that too many things were degraded into cl-*.
> And now very complex bad ideas are pushed as replacement fix.
> 
> >> > But within Emacs, I like using Emacs Lisp pure
> 
> Not sure what does "Emacs Lisp pure" mean.
> Does it mean "Whatever comes with Emacs except cl-* stuff."?
> 
> "Emacs Lisp pure" had CASE and ECASE in 1993 (conversion to RCS
> according to git) until 2012 iirc.

I prefer to use `cond' and avoid `if', and that `cl-*' stuff, I only
use in Common Lisp programs. Definition of pure Emacs Lisp is not
there, it was vague, not long lasting, and only withing the context
that was not supposed to be over commented. It disappeared already.

> > But Tomas, I mentioned nothing about pcase. I said cl- namespace being
> > separate feels liberating to me as my personal choice. If you wish to
> > use those commands without cl-prefix, there is solution that Stefan
> > wrote in recent email.
> 
> Bad workarounds do not fill me with joy.

His solution was just to load the library. How is it bad workaround?
But okay, if it is bad, sorry.

-- 
Jean Louis

Re: Advantage using mapc over dolist

[Heime via Users list for the GNU Emacs text editor]

On Wednesday, December 4th, 2024 at 8:04 AM, Tomas Hlavaty <tom@logand.com> wrote:

> On Tue 03 Dec 2024 at 22:24, Jean Louis bugs@gnu.support wrote:
> 
> > > > I am an Emacs Lisp programmer, and all Common Lisp functions
> > > > prefixed with `cl-` I find liberating in the sense that personally
> > > > within Emacs Lisp I do not like mixing it because it is not Common Lisp.
> 
> 
> Maybe the issue is that too many things were degraded into cl-*.
> And now very complex bad ideas are pushed as replacement fix.
> 
> > > > But within Emacs, I like using Emacs Lisp pure
> 
> 
> Not sure what does "Emacs Lisp pure" mean.
> Does it mean "Whatever comes with Emacs except cl-* stuff."?

The cl- prefix seems to indicate this.  The commands started to be explicit
that they are cl rather than elisp.  

For me, it should all be lisp.   
 
> "Emacs Lisp pure" had CASE and ECASE in 1993 (conversion to RCS
> according to git) until 2012 iirc.
> 
> > But Tomas, I mentioned nothing about pcase. I said cl- namespace being
> > separate feels liberating to me as my personal choice. If you wish to
> > use those commands without cl-prefix, there is solution that Stefan
> > wrote in recent email.
> 
> 
> Bad workarounds do not fill me with joy.
> 
> > > Anytime I process complex
> > > data recursively, I reach for labels. There does not seem to be an
> > > alternative, does it?
> > 
> > I have no idea about it, let me see what AI says:
> 
> 
> That AI is not good enough.
> The examples are too trivial to justify labels.
> 
> This function has a structure which does justify labels:
> 
> (defun parse-rss (dom)
> (let (z)
> (cl-labels ((link (x)
> (when (consp x)
> (cl-case (car x)
> (link (push (caddr x) z))
> (t (mapc #'link (cddr x))))))
> (rec (x)
> (when (consp x)
> (cl-case (car x)
> (item (link x))
> (t (mapc #'rec (cddr x)))))))
> (rec dom))
> (nreverse z)))
> 
> > So I would say, I would not get frustrated, rather just make an alias
> > for me and use `labels' wherever I wish and want.
> 
> 
> This does not address the problem.
> 
> In my Elisp code, I simply require cl-lib, add those cl- prefixes where
> needed and live with the result.
> 
> However, here simple and likely pre-CL functions and macros are degraded
> to cl-, people are discouraged from using cl- and encouraged to use
> something even more bonkers than cl-* ;-)

Re: Advantage using mapc over dolist

[Jean Louis]

* Heime <heimeborgia@protonmail.com> [2024-12-03 23:13]:
> > Not sure what does "Emacs Lisp pure" mean.
> > Does it mean "Whatever comes with Emacs except cl-* stuff."?
> 
> The cl- prefix seems to indicate this.  The commands started to be explicit
> that they are cl rather than elisp.  
> 
> For me, it should all be lisp.   

cl- prefix is like separating it in separate package so that we know
it is related to Common Lisp. And then each new package is supposed to
have different prefix.

cl- actually means Caffeinated Lispers (CL), but nobody wish to admit it.

-- 
Jean Louis

Re: Advantage using mapc over dolist

[Heime via Users list for the GNU Emacs text editor]

On Tuesday, December 3rd, 2024 at 8:41 AM, Tomas Hlavaty <tom@logand.com> wrote:

> On Mon 02 Dec 2024 at 18:30, Heime heimeborgia@protonmail.com wrote:
> 
> > I cannot see documentation for ecase or case!
> 
> hmm, somebody renamed it to cl-ecase and cl-case
> similar to flet -> cl-flet and labels -> cl-labels
> 
> what a shame

I agree

Re: Advantage using mapc over dolist

[Jean Louis]

* Heime via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2024-12-02 23:58]:
> 
> On Tuesday, December 3rd, 2024 at 8:41 AM, Tomas Hlavaty <tom@logand.com> wrote:
> 
> > On Mon 02 Dec 2024 at 18:30, Heime heimeborgia@protonmail.com wrote:
> > 
> > > I cannot see documentation for ecase or case!
> > 
> > hmm, somebody renamed it to cl-ecase and cl-case
> > similar to flet -> cl-flet and labels -> cl-labels
> > 
> > what a shame
> 
> I agree

Come on, that is just a stylish makeover!

-- 
Jean Louis

Re: Advantage using mapc over dolist

[Heime via Users list for the GNU Emacs text editor]

Sent with Proton Mail secure email.

On Wednesday, December 4th, 2024 at 7:26 AM, Jean Louis <bugs@gnu.support> wrote:

> * Heime via Users list for the GNU Emacs text editor help-gnu-emacs@gnu.org [2024-12-02 23:58]:
> 
> > On Tuesday, December 3rd, 2024 at 8:41 AM, Tomas Hlavaty tom@logand.com wrote:
> > 
> > > On Mon 02 Dec 2024 at 18:30, Heime heimeborgia@protonmail.com wrote:
> > > 
> > > > I cannot see documentation for ecase or case!
> > > 
> > > hmm, somebody renamed it to cl-ecase and cl-case
> > > similar to flet -> cl-flet and labels -> cl-labels
> > > 
> > > what a shame
> > 
> > I agree
> 
> 
> Come on, that is just a stylish makeover!

Sure.  But considering the historical frowning upon cl in emacs,
this this makes people wonder even more about whether to use them
or not, and when to use them.  There is no guide for people to decide.
The easiest and most efficient way is to disregard them.


 
> --
> Jean Louis

Re: Advantage using mapc over dolist

[Stefan Monnier via Users list for the GNU Emacs text editor]

>>           (pcase actm
>>            ('armg (do-this))
>>            ('go (do-that))))
>
> this does not justify pcase, use ecase or case instead

That's your personal preference.
My own personal preference is to forget about
case/cl/case/ecase/cl-ecase and just use `pcase` like the author
already did.

There's no need to "justify" the use of `pcase` for simple cases any
more than there's a need to justify the use of Emacs for trivial edits.


        Stefan

Re: Advantage using mapc over dolist

[Tomas Hlavaty]

On Tue 03 Dec 2024 at 09:11, Stefan Monnier via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> wrote:
>>>           (pcase actm
>>>            ('armg (do-this))
>>>            ('go (do-that))))
>>
>> this does not justify pcase, use ecase or case instead
>
> That's your personal preference.
> My own personal preference is to forget about
> case/cl/case/ecase/cl-ecase and just use `pcase` like the author
> already did.
>
> There's no need to "justify" the use of `pcase` for simple cases any
> more than there's a need to justify the use of Emacs for trivial edits.

on the contrary, it is better to use specific tools and avoid more
general tools when possible in order to lower cognitive load.

also the more general a tool is the less useful other orthogonal tools
become.  see how much nicer eldoc is with cl-case and cl-ecase?

Re: Advantage using mapc over dolist

[Stefan Monnier]

> on the contrary, it is better to use specific tools and avoid more
> general tools when possible in order to lower cognitive load.

Again, that's a personal preference.  If you have to learn the more
general tool anyway, then having to additionally learn the more specific
tool may increase rather than lower the cognitive load.

So you might in fact prefer to introduce another "simple case" construct
which uses the same syntax as `pcase` but supports only a strict subset
(the "simple" subset).  Of course, you don't need to learn all of
`pcase` in order to read&write the simple cases anyway, so we haven't
bothered to introduce such a construct.

> also the more general a tool is the less useful other orthogonal tools
> become.  see how much nicer eldoc is with cl-case and cl-ecase?

AFAICT the difference is unrelated to the difference in semantics
between the two tools, but is just the result of a different style of
writing in the docstring.

Maybe you're right that we should provide a more specific usage in the
docstring so that `C-h f` and Eldoc show something like

    (pcase EXP (PATTERN BODY...)...)

I don't have an opinion about that.


        Stefan

Re: Advantage using mapc over dolist

[Alfred M. Szmidt]

   > on the contrary, it is better to use specific tools and avoid more
   > general tools when possible in order to lower cognitive load.

   Again, that's a personal preference.  If you have to learn the more
   general tool anyway, then having to additionally learn the more specific
   tool may increase rather than lower the cognitive load.

Then why not use COND*?  

Frankly, this is one of the main issues why Alan got fed up.

I suggested adding ecase/case as proper non-CL macros a while back
(resounding silence).  There is no benefit in this code to use a very
complicated macro when a simpler one existed, and has easy semantics.

The usage of these complicated macros make generic and general code
much harder to reason about.  Renaming ecase/case was also one of
those things you did without much discussion, and it has nothing to do
with discouraging CL usage.

Re: Advantage using mapc over dolist

[Stefan Monnier]

>    > on the contrary, it is better to use specific tools and avoid more
>    > general tools when possible in order to lower cognitive load.
>    Again, that's a personal preference.  If you have to learn the more
>    general tool anyway, then having to additionally learn the more specific
>    tool may increase rather than lower the cognitive load.
> Then why not use COND*?  

AFAICT, the "cognitive load" of a complex pattern language is about the
same for `pcase` as for `match*` since the two pattern languages are
very similar.

And in the case of code that can use `case/ecase`, `cond*` doesn't seem
to provide much benefit over just `cond` or `pcase`.  Compare:

    (pcase actm
     ('armg (do-this))
     ('go (do-that))))

vs

    (case actm
     (armg (do-this))
     (go (do-that))))

vs

    (cond
     ((eq actm 'armg (do-this)))
     ((eq actm 'go (do-that))))

vs

    (cond*
     ((eq actm 'armg) (do-this))
     ((eq actm 'go) (do-that)))

or

    (cond*
     ((match* `armg actm) (do-this)))
     ((match* `go actm) (do-that))))


- Stefan

Re: Advantage using mapc over dolist

[Tomas Hlavaty]

On Tue 03 Dec 2024 at 12:24, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>>    > on the contrary, it is better to use specific tools and avoid more
>>    > general tools when possible in order to lower cognitive load.
>>    Again, that's a personal preference.  If you have to learn the more
>>    general tool anyway, then having to additionally learn the more specific
>>    tool may increase rather than lower the cognitive load.
>> Then why not use COND*?  
>
> AFAICT, the "cognitive load" of a complex pattern language is about the
> same for `pcase` as for `match*` since the two pattern languages are
> very similar.
>
> And in the case of code that can use `case/ecase`, `cond*` doesn't seem
> to provide much benefit over just `cond` or `pcase`.  Compare:

not only syntax but also semantics is important

not only things that are possible are important
but also things that are not possible

very limited stuff can happen using case/ecase

this is not the case with pcase so one has to keep in mind many more
possibilities

compare IF and WHEN.  IF is more general and using your logic, one
should use IF and forget WHEN.  however, the reduction of cognitive load
comes also from _things that cannot happen_, e.g. there is no "else"
branch to watch out for when using WHEN.  Thus writing (if x 42) is
worse than writing (when x 42).  It conveys the intention much better.
And is more robust.

>     (pcase actm
>      ('armg (do-this))
>      ('go (do-that))))

(let ((x 'go))
  (pcase x
    ('armg 1)
    ('go 2)))
=> 2
(let ((x 'go))
  (pcase x
    (armg 1)
    (go 2)))
=> 1

here the PATTERN leads to many more possibilities

>     (case actm
>      (armg (do-this))
>      (go (do-that))))

(let ((x 'go))
  (cl-case x
    ('armg 1)
    ('go 2)))
=> 2
(let ((x 'go))
  (cl-case x
    (armg 1)
    (go 2)))
=> 2

here the KEYLIST leads to much less possibilities

>     (cond
>      ((eq actm 'armg (do-this)))
>      ((eq actm 'go (do-that))))
>
> vs
>
>     (cond*
>      ((eq actm 'armg) (do-this))
>      ((eq actm 'go) (do-that)))
>
> or
>
>     (cond*
>      ((match* `armg actm) (do-this)))
>      ((match* `go actm) (do-that))))

obviously these examples are significantly worse than CASE

you meant:
(cond
  ((eq actm 'armg) (do-this))
  ((eq actm 'go) (do-that)))

and cond is simpler and more specific than cond*

so again, use simpler, more specific tool for the job and the code will
be more readable and maintainable

pushing for general omnipotent
use-me-i-can-do-everything-youll-ever-need macro is a bad idea

Re: Advantage using mapc over dolist

[Heime via Users list for the GNU Emacs text editor]

Sent with Proton Mail secure email.

On Wednesday, December 4th, 2024 at 7:27 AM, Tomas Hlavaty <tom@logand.com> wrote:

> On Tue 03 Dec 2024 at 12:24, Stefan Monnier monnier@iro.umontreal.ca wrote:
> 
> > > > on the contrary, it is better to use specific tools and avoid more
> > > > general tools when possible in order to lower cognitive load.
> > > > Again, that's a personal preference. If you have to learn the more
> > > > general tool anyway, then having to additionally learn the more specific
> > > > tool may increase rather than lower the cognitive load.
> > > > Then why not use COND*?
> > 
> > AFAICT, the "cognitive load" of a complex pattern language is about the
> > same for `pcase` as for `match*` since the two pattern languages are
> > very similar.
> > 
> > And in the case of code that can use `case/ecase`, `cond*` doesn't seem
> > to provide much benefit over just `cond` or `pcase`. Compare:
> 
> 
> not only syntax but also semantics is important
> 
> not only things that are possible are important
> but also things that are not possible
> 
> very limited stuff can happen using case/ecase
> 
> this is not the case with pcase so one has to keep in mind many more
> possibilities
> 
> compare IF and WHEN. IF is more general and using your logic, one
> should use IF and forget WHEN. however, the reduction of cognitive load
> comes also from things that cannot happen, e.g. there is no "else"
> branch to watch out for when using WHEN. Thus writing (if x 42) is
> worse than writing (when x 42). It conveys the intention much better.
> And is more robust.
> 
> > (pcase actm
> > ('armg (do-this))
> > ('go (do-that))))
> 
> 
> (let ((x 'go))
> (pcase x
> ('armg 1)
> ('go 2)))
> => 2
> 
> (let ((x 'go))
> (pcase x
> (armg 1)
> (go 2)))
> => 1
> 
> 
> here the PATTERN leads to many more possibilities
> 
> > (case actm
> > (armg (do-this))
> > (go (do-that))))
> 
> 
> (let ((x 'go))
> (cl-case x
> ('armg 1)
> ('go 2)))
> => 2
> 
> (let ((x 'go))
> (cl-case x
> (armg 1)
> (go 2)))
> => 2
> 
> 
> here the KEYLIST leads to much less possibilities
> 
> > (cond
> > ((eq actm 'armg (do-this)))
> > ((eq actm 'go (do-that))))
> > 
> > vs
> > 
> > (cond*
> > ((eq actm 'armg) (do-this))
> > ((eq actm 'go) (do-that)))
> > 
> > or
> > 
> > (cond*
> > ((match* `armg actm) (do-this))) ((match*` go actm) (do-that))))
> 
> 
> obviously these examples are significantly worse than CASE
> 
> you meant:
> (cond
> ((eq actm 'armg) (do-this))
> ((eq actm 'go) (do-that)))
> 
> and cond is simpler and more specific than cond*
> 
> so again, use simpler, more specific tool for the job and the code will
> be more readable and maintainable

You want to do same job, finding a specific command that has the capability
for doing nothing else than what you need is wasting your time.  But there
are many who like to delve on the technicalities about what they use, and
are not much interested is just getting the job done.
 
> pushing for general omnipotent
> use-me-i-can-do-everything-youll-ever-need macro is a bad idea

Total nonsense.  If a function can do what you need, use it.

Re: Advantage using mapc over dolist

[Tomas Hlavaty]

On Tue 03 Dec 2024 at 09:11, Stefan Monnier via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> wrote:
>>>           (pcase actm
>>>            ('armg (do-this))
>>>            ('go (do-that))))
>>
>> this does not justify pcase, use ecase or case instead
>
> That's your personal preference.
> My own personal preference is to forget about
> case/cl/case/ecase/cl-ecase and just use `pcase` like the author
> already did.

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.

Re: Advantage using mapc over dolist

[Tomas Hlavaty]

On Tue 03 Dec 2024 at 15:59, Tomas Hlavaty <tom@logand.com> wrote:
> On Tue 03 Dec 2024 at 09:11, Stefan Monnier via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> wrote:
>>>>           (pcase actm
>>>>            ('armg (do-this))
>>>>            ('go (do-that))))
>>>
>>> this does not justify pcase, use ecase or case instead
>>
>> That's your personal preference.
>> My own personal preference is to forget about
>> case/cl/case/ecase/cl-ecase and just use `pcase` like the author
>> already did.
>
> 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.

ecase comes from here:

   commit fcd737693e8e320acd70f91ec8e0728563244805
   Author: Richard M. Stallman <rms@gnu.org>
   Date:   Fri Jul 30 20:15:09 1993 +0000

       entered into RCS

renamed to cl-ecase here:

   commit 7c1898a7b93053cd0431f46f02d82c0a31bfb8bf
   Author: Stefan Monnier <monnier@iro.umontreal.ca>
   Date:   Sun Jun 3 21:05:17 2012 -0400

pcase comes from here:

   commit d02c9bcd096c44b4e3d5e2834c75967b56cdecdd
   Author: Stefan Monnier <monnier@iro.umontreal.ca>
   Date:   Tue Aug 10 15:18:14 2010 +0200

       * lisp/emacs-lisp/pcase.el: New file.

Not very nice to dismiss other peoples preferences as "just your
personal preference" while pushing through your personal preference.
That ecase macro was there for many decades, even before import to RCS
and you broke it and force your pcase way on everybody.  The author used
pcase because of you, not very good argument for pcase merit.

Re: Advantage using mapc over dolist

[Tomas Hlavaty]

On Tue 03 Dec 2024 at 16:40, Tomas Hlavaty <tom@logand.com> wrote:
> On Tue 03 Dec 2024 at 15:59, Tomas Hlavaty <tom@logand.com> wrote:
>> On Tue 03 Dec 2024 at 09:11, Stefan Monnier via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> wrote:
>>>>>           (pcase actm
>>>>>            ('armg (do-this))
>>>>>            ('go (do-that))))
>>>>
>>>> this does not justify pcase, use ecase or case instead
>>>
>>> That's your personal preference.
>>> My own personal preference is to forget about
>>> case/cl/case/ecase/cl-ecase and just use `pcase` like the author
>>> already did.
>>
>> 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.
>
> ecase comes from here:
>
>    commit fcd737693e8e320acd70f91ec8e0728563244805
>    Author: Richard M. Stallman <rms@gnu.org>
>    Date:   Fri Jul 30 20:15:09 1993 +0000
>
>        entered into RCS
>
> renamed to cl-ecase here:
>
>    commit 7c1898a7b93053cd0431f46f02d82c0a31bfb8bf
>    Author: Stefan Monnier <monnier@iro.umontreal.ca>
>    Date:   Sun Jun 3 21:05:17 2012 -0400
>
> pcase comes from here:
>
>    commit d02c9bcd096c44b4e3d5e2834c75967b56cdecdd
>    Author: Stefan Monnier <monnier@iro.umontreal.ca>
>    Date:   Tue Aug 10 15:18:14 2010 +0200
>
>        * lisp/emacs-lisp/pcase.el: New file.
>
> Not very nice to dismiss other peoples preferences as "just your
> personal preference" while pushing through your personal preference.
> That ecase macro was there for many decades, even before import to RCS
> and you broke it and force your pcase way on everybody.  The author used
> pcase because of you, not very good argument for pcase merit.

And now thanks to pcase there is also cond*.
What a mess.

Re: Advantage using mapc over dolist

[Eli Zaretskii]

> From: Tomas Hlavaty <tom@logand.com>
> Date: Tue, 03 Dec 2024 16:57:10 +0100
> 
> And now thanks to pcase there is also cond*.
> What a mess.

I honestly don't understand why having several more-or-less equivalent
forms, all accepted and used, so that each user can use whatever he or
she likes, is "a mess".  In my book, it's "user-friendliness", let
alone "flexibility".

Re: Advantage using mapc over dolist

[Tomas Hlavaty]

On Tue 03 Dec 2024 at 19:11, Eli Zaretskii <eliz@gnu.org> wrote:
>> And now thanks to pcase there is also cond*.
>> What a mess.
>
> I honestly don't understand why having several more-or-less equivalent
> forms, all accepted and used, so that each user can use whatever he or
> she likes, is "a mess".  In my book, it's "user-friendliness", let
> alone "flexibility".

I would agree if there still were traditional CASE, ECASE etc. so that
there would be

   several more-or-less equivalent forms, all accepted and used, so that
   each user can use whatever he or she likes

But this is exactly the point, that what you suggest is not true but
should be.

Re: Advantage using mapc over dolist

[Eli Zaretskii]

> From: Tomas Hlavaty <tom@logand.com>
> Date: Tue, 03 Dec 2024 18:33:20 +0100
> 
> On Tue 03 Dec 2024 at 19:11, Eli Zaretskii <eliz@gnu.org> wrote:
> >> And now thanks to pcase there is also cond*.
> >> What a mess.
> >
> > I honestly don't understand why having several more-or-less equivalent
> > forms, all accepted and used, so that each user can use whatever he or
> > she likes, is "a mess".  In my book, it's "user-friendliness", let
> > alone "flexibility".
> 
> I would agree if there still were traditional CASE, ECASE etc. so that
> there would be
> 
>    several more-or-less equivalent forms, all accepted and used, so that
>    each user can use whatever he or she likes
> 
> But this is exactly the point, that what you suggest is not true but
> should be.

If your only gripe is about the names of cl-case and cl-ecase, then
why mention pcase and cond*? they were not renamed and didn't come
from CL.  And why is it "a mess"?  You've made abundantly clear that
you didn't like the cl- names, why is there a need to add unrelated
accusations?

Re: Advantage using mapc over dolist

[Tomas Hlavaty]

On Tue 03 Dec 2024 at 19:40, Eli Zaretskii <eliz@gnu.org> wrote:
> If your only gripe is about the names of cl-case and cl-ecase, then
> why mention pcase and cond*? they were not renamed and didn't come
> from CL.  And why is it "a mess"?  You've made abundantly clear that
> you didn't like the cl- names, why is there a need to add unrelated
> accusations?

in short, because people are directed to use pcase as the replacement
for case and pcase-exhaustive as replacement for ecase

Re: Advantage using mapc over dolist

[Heime via Users list for the GNU Emacs text editor]

Sent with Proton Mail secure email.

On Wednesday, December 4th, 2024 at 5:55 AM, Tomas Hlavaty <tom@logand.com> wrote:

> On Tue 03 Dec 2024 at 19:40, Eli Zaretskii eliz@gnu.org wrote:
> 
> > If your only gripe is about the names of cl-case and cl-ecase, then
> > why mention pcase and cond*? they were not renamed and didn't come
> > from CL. And why is it "a mess"? You've made abundantly clear that
> > you didn't like the cl- names, why is there a need to add unrelated
> > accusations?
> 
> 
> in short, because people are directed to use pcase as the replacement
> for case and pcase-exhaustive as replacement for ecase


I agree.  Everyone is aware about the historical discouragement about cl
things, but we have no understanding if such discouragement is still relevant
today.  We need some certainty so we can adapt our code accordingly.

Re: Advantage using mapc over dolist

[Alfred M. Szmidt]

   > > If your only gripe is about the names of cl-case and cl-ecase, then
   > > why mention pcase and cond*? they were not renamed and didn't come
   > > from CL. And why is it "a mess"? You've made abundantly clear that
   > > you didn't like the cl- names, why is there a need to add unrelated
   > > accusations?
   > 
   > in short, because people are directed to use pcase as the replacement
   > for case and pcase-exhaustive as replacement for ecase

   I agree.  Everyone is aware about the historical discouragement about cl
   things, but we have no understanding if such discouragement is still relevant
   today.  We need some certainty so we can adapt our code accordingly.

ecase, and case are older than CL.  

But this isn't so much about CL or not CL.  If CL has specific useful
macros or functions, they surley can be added to Emacs Lisp if there
is good reasons for them.  Emacs Lisp isn't CL and doesn't try to be,
for very good reasons.

Re: Advantage using mapc over dolist

[Heime via Users list for the GNU Emacs text editor]

On Wednesday, December 4th, 2024 at 6:57 AM, Alfred M. Szmidt <ams@gnu.org> wrote:

> > > If your only gripe is about the names of cl-case and cl-ecase, then
> 
> > > why mention pcase and cond*? they were not renamed and didn't come
> 
> > > from CL. And why is it "a mess"? You've made abundantly clear that
> 
> > > you didn't like the cl- names, why is there a need to add unrelated
> 
> > > accusations?
> 
> > in short, because people are directed to use pcase as the replacement
> 
> > for case and pcase-exhaustive as replacement for ecase
> 
> 
> I agree. Everyone is aware about the historical discouragement about cl
> things, but we have no understanding if such discouragement is still relevant
> today. We need some certainty so we can adapt our code accordingly.
> 
> ecase, and case are older than CL.
> 
> But this isn't so much about CL or not CL. If CL has specific useful
> macros or functions, they surley can be added to Emacs Lisp if there
> is good reasons for them. 

> Emacs Lisp isn't CL and doesn't try to be, for very good reasons.
 
Actually it is about CL or not CL.  Otherwise there would not have been 
the comment above.

The confusion in emacs self-mode.  Because eventually the cl- things get
introduced and nobody knows what the hell we are supposed to do with them.

In my school of thought, if you introduce them, people will use them.  But
then the maintainers let people hang themselves using them, because the 
documentation refrains from a good enough explanation about their use.  

Re: Advantage using mapc over dolist

[Tomas Hlavaty]

On Tue 03 Dec 2024 at 13:57, "Alfred M. Szmidt" <ams@gnu.org> wrote:
> ecase, and case are older than CL.

That's what I thought, do you have any pointers?

Re: Advantage using mapc over dolist

[Alfred M. Szmidt]

   On Tue 03 Dec 2024 at 13:57, "Alfred M. Szmidt" <ams@gnu.org> wrote:
   > ecase, and case are older than CL.

   That's what I thought, do you have any pointers?

Lisp Machine?  CASE was called SELECTQ at one point.

Re: Advantage using mapc over dolist

[Jean Louis]

* Tomas Hlavaty <tom@logand.com> [2024-12-03 18:42]:
> Not very nice to dismiss other peoples preferences as "just your
> personal preference" while pushing through your personal preference.
> That ecase macro was there for many decades, even before import to RCS
> and you broke it and force your pcase way on everybody.  The author used
> pcase because of you, not very good argument for pcase merit.

But sorry, isn't all programming in Emacs Lisp "pushing personal
preferences"? Of course people discuss about it, but it is all
personal in first place. Whatever you programmed into Emacs was for
you personally useful and I am using it now, thanks.

In pcase someone tries to force pcase onto me, I will defend myself
with machete.

-- 
Jean Louis

Re: Advantage using mapc over dolist

[Heime via Users list for the GNU Emacs text editor]

On Wednesday, December 4th, 2024 at 7:42 AM, Jean Louis <bugs@gnu.support> wrote:

> * Tomas Hlavaty tom@logand.com [2024-12-03 18:42]:
> 
> > Not very nice to dismiss other peoples preferences as "just your
> > personal preference" while pushing through your personal preference.
> > That ecase macro was there for many decades, even before import to RCS
> > and you broke it and force your pcase way on everybody. The author used
> > pcase because of you, not very good argument for pcase merit.
 
I did not.  My interest was about mapc only   
 
> But sorry, isn't all programming in Emacs Lisp "pushing personal
> preferences"? Of course people discuss about it, but it is all
> personal in first place. Whatever you programmed into Emacs was for
> you personally useful and I am using it now, thanks.
> 
> In pcase someone tries to force pcase onto me, I will defend myself
> with machete.
> 
> --
> Jean Louis

Re: Advantage using mapc over dolist

[Jean Louis]

* Heime <heimeborgia@protonmail.com> [2024-12-03 22:54]:
> 
> On Wednesday, December 4th, 2024 at 7:42 AM, Jean Louis <bugs@gnu.support> wrote:
> 
> > * Tomas Hlavaty tom@logand.com [2024-12-03 18:42]:
> > 
> > > Not very nice to dismiss other peoples preferences as "just your
> > > personal preference" while pushing through your personal preference.
> > > That ecase macro was there for many decades, even before import to RCS
> > > and you broke it and force your pcase way on everybody. The author used
> > > pcase because of you, not very good argument for pcase merit.
>  
> I did not.  My interest was about mapc only   

I was heavy user of `dolist'. I am not fan of it any more. I have
still shameful 126 occurences which I have to replace with `while'.

-- 
Jean Louis

Re: Advantage using mapc over dolist

[Stefan Monnier]

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

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.

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

Re: Advantage using mapc over dolist

[Heime via Users list for the GNU Emacs text editor]

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

Re: Advantage using mapc over dolist

[Jean Louis]

* 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

Re: Advantage using mapc over dolist

[Tomas Hlavaty]

On Tue 03 Dec 2024 at 11:47, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> 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`.

How did you decide what should be renamed to cl-*?

Don't you think you overdone it, that too much was renamed?

Why was IF not renamed to cl-if?

Why do you think CASE is CL?

> While some people were happy because they consider that ELisp is better
> off without those Common Lisp constructs

How do you feel about code like this?

(defun tempo-is-user-element (element)
  "Try all the user-defined element handlers in `tempo-user-elements'."
  ;; Sigh... I need (some list)
  (catch 'found
    (mapc (lambda (handler)
            (let ((result (funcall handler element)))
              (if result (throw 'found result))))
	  tempo-user-elements)
    (throw 'found nil)))

Do you think duplicating SOME this way is better than embracing SOME?

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

In my code I just require cl-lib and add the cl- prefix where needed and
live with that.

But here we are discussing Emacs code, the way it is evolving and the
future problems it will bring.

Re: Advantage using mapc over dolist

[Stefan Monnier]

>> 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`.
> How did you decide what should be renamed to cl-*?

Everything that was defined in the CL library.

> Why was IF not renamed to cl-if?

Because `if` was never defined in the CL library but in
`eval.c` (and the byte-compiler).

> Why do you think CASE is CL?

Because it's defined in `cl-macs.el`, i.e. in the CL library (tho this
file now belongs to the CL-Lib library).

The renaming was motivated by very practical constraints, so there was
very little opinion involved in which things were renamed and which weren't.

"Very little" is not the same as "no opinion", admittedly.  For example,
I did refrain from renaming `setf` and instead re-implemented it outside
of CL-Lib, integrating it into "core ELisp".

Also, we later re-re-named things like `cl-caadr` to just `caadr`
(i.e. integrating it into "core Elisp").

> How do you feel about code like this?
>
> (defun tempo-is-user-element (element)
>   "Try all the user-defined element handlers in `tempo-user-elements'."
>   ;; Sigh... I need (some list)
>   (catch 'found
>     (mapc (lambda (handler)
>             (let ((result (funcall handler element)))
>               (if result (throw 'found result))))
> 	  tempo-user-elements)
>     (throw 'found nil)))
>
> Do you think duplicating SOME this way is better than embracing SOME?

Personally, I think it should (require 'cl-lib) and then use `cl-some`.

> In my code I just require cl-lib and add the cl- prefix where needed and
> live with that.

Same here.


        Stefan

Re: Advantage using mapc over dolist

[Heime via Users list for the GNU Emacs text editor]

Sent with Proton Mail secure email.

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

> > > 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`.
> > > How did you decide what should be renamed to cl-*?
> 
> 
> Everything that was defined in the CL library.
> 
> > Why was IF not renamed to cl-if?
> 
> 
> Because `if` was never defined in the CL library but in
> `eval.c` (and the byte-compiler).
> 
> > Why do you think CASE is CL?
> 
> 
> Because it's defined in `cl-macs.el`, i.e. in the CL library (tho this
> file now belongs to the CL-Lib library).
> 
> The renaming was motivated by very practical constraints, so there was
> very little opinion involved in which things were renamed and which weren't.
> 
> "Very little" is not the same as "no opinion", admittedly. For example,
> I did refrain from renaming `setf` and instead re-implemented it outside
> of CL-Lib, integrating it into "core ELisp".
> 
> Also, we later re-re-named things like `cl-caadr` to just `caadr`
> (i.e. integrating it into "core Elisp").
> 
> > How do you feel about code like this?
> > 
> > (defun tempo-is-user-element (element)
> > "Try all the user-defined element handlers in `tempo-user-elements'."
> > ;; Sigh... I need (some list)
> > (catch 'found
> > (mapc (lambda (handler)
> > (let ((result (funcall handler element)))
> > (if result (throw 'found result))))
> > tempo-user-elements)
> > (throw 'found nil)))
> > 
> > Do you think duplicating SOME this way is better than embracing SOME?
> 
> 
> Personally, I think it should (require 'cl-lib) and then use `cl-some`.

That was the code I wrote.  What are you talking about?  How does a simple
question end up like this, with the OP completely disregarded so you can all
argue between yourselves!
 
> > In my code I just require cl-lib and add the cl- prefix where needed and
> > live with that.
> 
> 
> Same here.
> 
> 
> Stefan

Re: Advantage using mapc over dolist

[Stefan Monnier via Users list for the GNU Emacs text editor]

> That was the code I wrote.  What are you talking about?  How does a simple
> question end up like this, with the OP completely disregarded so you can all
> argue between yourselves!

Indeed we hijacked your thread, sorry,


        Stefan

Re: Advantage using mapc over dolist

[Jean Louis]

* Tomas Hlavaty <tom@logand.com> [2024-12-03 18:01]:
> On Tue 03 Dec 2024 at 09:11, Stefan Monnier via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> wrote:
> >>>           (pcase actm
> >>>            ('armg (do-this))
> >>>            ('go (do-that))))
> >>
> >> this does not justify pcase, use ecase or case instead
> >
> > That's your personal preference.
> > My own personal preference is to forget about
> > case/cl/case/ecase/cl-ecase and just use `pcase` like the author
> > already did.
> 
> 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.

No infection here, no monstrosity on my side, and nobody forced me
anything, in fact I have highest joy with Emacs Lisp.

I remember `dlet*' was like this:

(defmacro rcd-dlet (binders &rest body)
  "Like `let*' but using dynamic scoping.

Argument BINDERS behaves similarly like `let' with the difference
that variables become global even under lexical scope.

Optional argument BODY will be executed."
  (declare (indent 1) (debug let))
  ;; (defvar FOO) only affects the current scope, but in order for
  ;; this not to affect code after the main `let' we need to create a new scope,
  ;; which is what the surrounding `let' is for.
  ;; FIXME: (let () ...) currently doesn't actually create a new scope,
  ;; which is why we use (let (_) ...).
  `(let (_)
     ,@(mapcar (lambda (binder)
                 `(defvar ,(if (consp binder) (car binder) binder)))
               binders)
     (let* ,binders ,@body)))

but someone changed it substantially:

(defmacro dlet (binders &rest body)
  "Like `let' but using dynamic scoping."
  (declare (indent 1) (debug let))
  ;; (defvar FOO) only affects the current scope, but in order for
  ;; this not to affect code after the main `let' we need to create a new scope,
  ;; which is what the surrounding `let' is for.
  ;; FIXME: (let () ...) currently doesn't actually create a new scope,
  ;; which is why we use (let (_) ...).
  `(let (_)
     ,@(mapcar (lambda (binder)
                 `(defvar ,(if (consp binder) (car binder) binder)))
               binders)
     (let ,binders ,@body)))

That small difference was changed, and I was feeling about you:

(let* ,binders ,@body)

and I complained, because I did not realize how easy it is to make it
how I want, so I stole the function and it is done and well!

In fact, it is possible to make a package aliasing all cl- functions and it is done.

-- 
Jean Louis

Re: Advantage using mapc over dolist

[Michael Heerdegen via Users list for the GNU Emacs text editor]

Tomas Hlavaty <tom@logand.com> writes:

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

Come on, nobody is forcing you to anything.  I know it is fashionable to
be pissed nowadays, but let's not exaggerate.  BTW, talking about
respect while calling something others prefer a "monstrosity" doesn't look
like a consistent perspective to me.

Let's compare:

In a fresh emacs -Q

  (featurep 'cl-lib) -> nil

as well as

  (featurep 'pcase) -> nil

`pcase' isn't privileged at all.

So load what you want and use what you want like known from any
modularized language and good it is.  Should Emacs load everything it
can at startup just so that nobody will barf that her/his favorite toy
is of course available without a simple `require' call?

I also never understood why people prefer to have extremely short names
as an optimum, and the hell breaks lose if they have to use three more
letters.

Just stop being annoyed, and everything is good.


Michael.

Re: Advantage using mapc over dolist

[Tassilo Horn]

Heime via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> writes:

> Is there any advantage using mapc over dolist when looping through
> a list passed as argument to a function?

Not in you example.  It can be "better" in terms of brevety when you
already have the function defined which you want to execute on each
element of the list.  Say, that function was foo, then

  (mapc #'foo list)

is a bit shorter than

  (dolist (item list)
    (foo item))

But it's essentially a question of preference.

Bye,
Tassilo

Re: Advantage using mapc over dolist

[Michael Heerdegen via Users list for the GNU Emacs text editor]

Tassilo Horn <tsdh@gnu.org> writes:

> But it's essentially a question of preference.

Yes, that.

If execution speed is crucial, IIRC at least for byte compiled code the
`dolist' version generates significantly faster code.

Michael.

Re: Advantage using mapc over dolist

[Heime via Users list for the GNU Emacs text editor]

Sent with Proton Mail secure email.

On Monday, December 2nd, 2024 at 10:12 PM, Michael Heerdegen via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> wrote:

> Tassilo Horn tsdh@gnu.org writes:
> 
> > But it's essentially a question of preference.
> 
> 
> Yes, that.
> 
> If execution speed is crucial, IIRC at least for byte compiled code the
> `dolist' version generates significantly faster code.
> 
> Michael.


Did not know that.  Had thought the mapc would be faster.  With dolist
I can exit with (return) or catch-throw, can one do the same with mapc?

For what cases is mapc useful?

Re: Advantage using mapc over dolist

[Tomas Hlavaty]

On Mon 02 Dec 2024 at 17:03, Heime via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> wrote:
> Had thought the mapc would be faster.

mapc calls a function (length list) times, so unless the compiler is
clever enough to optimize this call away, it will be "slower"

however, if you want fast code, do not traverse lists whole and linearly
in the first place.  instead, try to place the loop as far outside as
possible

> With dolist I can exit with (return) or catch-throw, can one do the
> same with mapc?

yes

> For what cases is mapc useful?

for side-effects, if you have the body of the loop as a function
already

Re: Advantage using mapc over dolist

[Heime via Users list for the GNU Emacs text editor]

Sent with Proton Mail secure email.

On Tuesday, December 3rd, 2024 at 6:51 AM, Tomas Hlavaty <tom@logand.com> wrote:

> On Mon 02 Dec 2024 at 17:03, Heime via Users list for the GNU Emacs text editor help-gnu-emacs@gnu.org wrote:
> 
> > Had thought the mapc would be faster.
> 
> 
> mapc calls a function (length list) times, so unless the compiler is
> clever enough to optimize this call away, it will be "slower"
> 
> however, if you want fast code, do not traverse lists whole and linearly
> in the first place. instead, try to place the loop as far outside as
> possible
> 
> > With dolist I can exit with (return) or catch-throw, can one do the
> > same with mapc?
> 
> 
> yes

How can I find an example of exiting prematurely from mapc?
 
> > For what cases is mapc useful?
> 
> 
> for side-effects, if you have the body of the loop as a function
> already

I see

Re: Advantage using mapc over dolist

[Tomas Hlavaty]

On Mon 02 Dec 2024 at 20:17, Heime <heimeborgia@protonmail.com> wrote:
> How can I find an example of exiting prematurely from mapc?

silly example:

(catch 'done
  (let ((z 0))
    (mapc (lambda (x)
            (if (< x 10)
                (setq z (+ z x))
              (throw 'done z)))
          '(3 5 7 13))))

You can search emacs sources for mapc.
I have a custom rg-emacs function for that:

(rg-emacs "mapc ")

which finds tempo-is-user-element function showing something
interesting:

(defun tempo-is-user-element (element)
  "Try all the user-defined element handlers in `tempo-user-elements'."
  ;; Sigh... I need (some list)
  (catch 'found
    (mapc (lambda (handler)
            (let ((result (funcall handler element)))
              (if result (throw 'found result))))
	  tempo-user-elements)
    (throw 'found nil)))

although in Common Lisp, I would avoid catch, throw and mapc and used
dolist with return or return-from instead:

(defun tempo-is-user-element (element)
  (dolist (handler tempo-user-elements)
    (let ((z (funcall handler element)))
      (when z
        (cl-return z)))))

This is more readable than the catch, mapc, throw code in Emacs.

Unfortunately, cl-return-from does not seems to be as convenient.
cl-return might do what I expect cl:return to be doing.

Re: Advantage using mapc over dolist

[Tomas Hlavaty]

On Mon 02 Dec 2024 at 22:07, Tomas Hlavaty <tom@logand.com> wrote:
> (defun tempo-is-user-element (element)
>   "Try all the user-defined element handlers in `tempo-user-elements'."
>   ;; Sigh... I need (some list)
>   (catch 'found
>     (mapc (lambda (handler)
>             (let ((result (funcall handler element)))
>               (if result (throw 'found result))))
> 	  tempo-user-elements)
>     (throw 'found nil)))
>
> although in Common Lisp, I would avoid catch, throw and mapc and used
> dolist with return or return-from instead:
>
> (defun tempo-is-user-element (element)
>   (dolist (handler tempo-user-elements)
>     (let ((z (funcall handler element)))
>       (when z
>         (cl-return z)))))
>
> This is more readable than the catch, mapc, throw code in Emacs.
>
> Unfortunately, cl-return-from does not seems to be as convenient.
> cl-return might do what I expect cl:return to be doing.

and as the comment in tempo-is-user-element says, this is also nice
example, how longing for "liberating feeling" leads to duplicating the
same code all over the place, badly.  If only there was SOME in Emacs
lisp instead of cl-lib?  Such a simple and useful function.  It even
does not have keyword arguments.

RE: [External] : Re: Advantage using mapc over dolist

[Drew Adams]

What others have said in this thread is all good/correct.

Maybe it's worth pointing out that using mapping and other sequence-processing functions is common in (real) functional languages, especially in purely functional (lazy) languages.

The benefits and performance considerations are different for such languages. Among other things, such a programming style helps you think at the level of streams or functions that operate on them, rather than thinking at the level of the individual objects acted on in the streams.

OOTB Lisp isn't really made for such streaming-style programming.

https://en.wikipedia.org/wiki/Function-level_programming

RE: [External] : Re: Advantage using mapc over dolist

[Tomas Hlavaty]

On Mon 02 Dec 2024 at 21:15, Drew Adams <drew.adams@oracle.com> wrote:
> OOTB Lisp isn't really made for such streaming-style programming.

Lisp is great for streaming-style programming:

;; -*- lexical-binding: t -*-

(defun stream (x)
  (cl-etypecase x
    (list
     (lambda ()
       (pop x)))
    (array
     (let ((n (length x))
           (i 0))
       (lambda ()
         (when (< i n)
           (prog1 (aref x i)
             (setq i (1+ i)))))))))

(defun collect (stream)
  (cl-loop
   with x
   while (setq x (funcall stream))
   collect x))

(collect (stream '(1 2 3 4))
(collect (stream [1 2 3 4]))

(defun random-stream (&optional limit)
  (lambda ()
    (random limit)))

(defun head-stream (stream n)
  (lambda ()
    (when (<= 0 (setq n (1- n)))
      (let ((z (funcall stream)))
        (unless z
          (setq n 0))
        z))))

(collect (head-stream (stream '(1 2 3 4)) 3))
(collect (head-stream (stream '(1 2)) 3))
(collect (head-stream (random-stream 6) 10))

(defun map-stream (stream fn)
  (lambda ()
    (let ((x (funcall stream)))
      (when x
        (funcall fn x)))))

(collect (map-stream (head-stream (random-stream 6) 10) #'1+))

(defun message-stream (stream)
  (lambda ()
    (let ((x (funcall stream)))
      (message "%s" (prin1-to-string x))
      x)))

(defun sleep-stream (stream seconds)
  (lambda ()
    (let ((z (funcall stream)))
      (when z
        (sleep-for seconds)
        z))))

(collect (sleep-stream (message-stream (head-stream (random-stream 6) 10)) 1))

(defun fibonacci-stream ()
  (let ((a 0)
        (b 1))
    (lambda ()
      (cl-shiftf a b (+ a b)))))

(collect (head-stream (fibonacci-stream) 10))

Now lots of things can be such a stream.

(defun deadline-stream (stream deadline)
  (lambda ()
    ;; what is the Emacs replacement for get-universal-time?
    (if (< (get-universal-time) deadline)
        (funcall stream)
        (error "deadline ~s reached" deadline))))

Imagine a web application.  It can be seen as such a stream where users
funcall the stream with their clicks and keystrokes.  A widget is also
just another stream and can also contain other widgets which are also
just another stream.

The nice thing about these streams is how declaratively their
definitions feel.  Almost like a declarative reactive dataflow
synchronous language.

RE: [External] : Re: Advantage using mapc over dolist

[Drew Adams]

> > OOTB Lisp isn't really made for such streaming-style programming.
> 
> Lisp is great for streaming-style programming:

You can implement anything in Lisp, including streams. (They were _first_ implemented in Lisp, BTW - see ref.)

That doesn't mean that out-of-the-box ("OOTB") Lisp is designed for stream-oriented programming.  Certainly not in the sense of what a purely functional (normal order/lazy-evaluation) language is.
___

https://help.luddy.indiana.edu/techreports/TRNNN.cgi?trnum=TR44

RE: [External] : Re: Advantage using mapc over dolist

[Tomas Hlavaty]

On Mon 02 Dec 2024 at 22:42, Drew Adams <drew.adams@oracle.com> wrote:
> That doesn't mean that out-of-the-box ("OOTB") Lisp is designed for
> stream-oriented programming.  Certainly not in the sense of what a
> purely functional (normal order/lazy-evaluation) language is.  ___

lazy evaluation is what those LAMBDAs and FUNCALLs in my examples are
about.

purely functional languages are not about implicit lazy-evaluation, see
purescript for example.

Lazy functional programming [was: Advantage using mapc over dolist]

[Drew Adams]

> From: Tomas Hlavaty
> Sent: Monday, December 2, 2024 9:50 PM
>
> lazy evaluation is what those LAMBDAs and
> FUNCALLs in my examples are about.

Yes, in effect you're _implementing_ lazy
evaluation here & there by using lambdas to
delay evaluation.  That's classic, but it's
not general lazy evaluation.  Explicit
do-something-lazy-here is different from
inherent laziness.

Similarly, lazy `cons' (Friedman & Wise)
isn't general lazy evaluation.  That provides
only lazy lists.

> purely functional languages are not about
> implicit lazy-evaluation, see purescript

It's really a matter of opinion - there's no
single, formal "purely functional" definition.
Meanings usually include characteristics such
as "side-effect free" and "referentially
transparent", but there can be more.

Applicative-order (strict/eager) evaluation
isn't, and normal-order (lazy) evaluation is,
guaranteed to terminate and return a correct
result - a big  difference when it comes to 
programming with functions.

Some evaluation strategies converge and others
may not.  Using "purely functional" only for
those that do makes sense to me.  This includes
normal-order (leftmost-outermost) evaluation,
and it includes optimal call-by-need rewrite 
strategies (only necessary reductions).
___

I recommend John Hughes's classic 1984 paper
"Why Functional Programming Matters".  See here
an excerpt from it that points to laziness and
higher-order functions as the "glue" that holds
functional programs together, as well as John's
own description of the paper.

https://www.emacswiki.org/emacs/DrewAdams#WhyFunctionalProgrammingMatters

By "glue" he's talking about modularity:

 "The ways in which one can divide up the
  original problem depend directly on the ways
  in which one can glue solutions together."

It's about the modularity advantages provided
by higher-order functions and lazy evaluation.

That they play this role of glue for functional 
programming is germane to the question about
heavy use of `mapc' and the like in Lisp.

(That doesn't mean that smart compilation and
some fiddling might sometimes work around the
lack of real support for them in Lisp.)

The paper itself is here:

https://www.cse.chalmers.se/~rjmh/Papers/whyfp.pdf

See also this page:

https://www.cse.chalmers.se/~rjmh/citations/my_most_influential_papers.htm

Re: Lazy functional programming [was: Advantage using mapc over dolist]

[Tomas Hlavaty]

On Tue 03 Dec 2024 at 20:08, Drew Adams <drew.adams@oracle.com> wrote:
>>> That doesn't mean that out-of-the-box ("OOTB") Lisp is designed for
>>> stream-oriented programming.

What are you hinting at?
Optimizing away those FUNCALLs?
Or something else?

>> purely functional languages are not about
>> implicit lazy-evaluation, see purescript
>
> It's really a matter of opinion - there's no
> single, formal "purely functional" definition.

Do you not consider purescript, elm, idris2 "purely functional
languages"?

> Applicative-order (strict/eager) evaluation
> isn't, and normal-order (lazy) evaluation is,
> guaranteed to terminate and return a correct
> result - a big  difference when it comes to 
> programming with functions.

That sounds suspicious.
Is the trick in the meaning of "guaranteed"?

> I recommend John Hughes's classic 1984 paper
> "Why Functional Programming Matters".  See here
> an excerpt from it that points to laziness and
> higher-order functions as the "glue" that holds
> functional programs together, as well as John's
> own description of the paper.
>
> https://www.emacswiki.org/emacs/DrewAdams#WhyFunctionalProgrammingMatters
>
> By "glue" he's talking about modularity:
>
>  "The ways in which one can divide up the
>   original problem depend directly on the ways
>   in which one can glue solutions together."
>
> It's about the modularity advantages provided
> by higher-order functions and lazy evaluation.
>
> That they play this role of glue for functional 
> programming is germane to the question about
> heavy use of `mapc' and the like in Lisp.
>
> (That doesn't mean that smart compilation and
> some fiddling might sometimes work around the
> lack of real support for them in Lisp.)
>
> The paper itself is here:
>
> https://www.cse.chalmers.se/~rjmh/Papers/whyfp.pdf
>
> See also this page:
>
> https://www.cse.chalmers.se/~rjmh/citations/my_most_influential_papers.htm

Thanks for the links!

Re: Advantage using mapc over dolist

[Michael Heerdegen]

Tomas Hlavaty <tom@logand.com> writes:

> > Had thought the mapc would be faster.
>
> mapc calls a function (length list) times, so unless the compiler is
> clever enough to optimize this call away, it will be "slower"

Of course the same argument would hold for `dolist'.  You can rewrite
any `dolist' expression to an equivalent `mapc' call and vice versa.

Which one is faster can only be explained by looking at the
implementation of the language.  In case of Emacs Lisp, `while' loops
are the most efficient way of looping, and `dolist' expands to `while'.

It could be the other way round for a different Emacs Lisp compiler.


Michael.