cl-loop - do you understand it well?

cl-loop - do you understand it well?

[Emanuel Berg]

So what is this eval'd to - an why?

Hint: All and any method is allowed!

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

(require 'cl-lib)

(cl-loop
  for i from 0 to 1
  collect (lambda () i) into funs
  finally return (apply #'+ (mapcar #'funcall funs)) )

-- 
underground experts united
https://dataswamp.org/~incal

Re: cl-loop - do you understand it well?

[Michael Heerdegen]

Emanuel Berg <incal@dataswamp.org> writes:

> So what is this eval'd to - an why?

The answer to the question in the subject is easier: No!


> Hint: All and any method is allowed!
>
> ;;; -*- lexical-binding: t -*-
>
> (require 'cl-lib)
>
> (cl-loop
>   for i from 0 to 1
>   collect (lambda () i) into funs
>   finally return (apply #'+ (mapcar #'funcall funs)) )

Any method?  I would like to test it with Emacs 31.  Would it make a
difference?

Honestly: Do the cl-loop fans think we should change the behavior?


Michael.

Re: cl-loop - do you understand it well?

[Akib Azmain Turja]

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

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Emanuel Berg <incal@dataswamp.org> writes:
>
>> So what is this eval'd to - an why?
>
> The answer to the question in the subject is easier: No!
>
>
>> Hint: All and any method is allowed!
>>
>> ;;; -*- lexical-binding: t -*-
>>
>> (require 'cl-lib)
>>
>> (cl-loop
>>   for i from 0 to 1
>>   collect (lambda () i) into funs
>>   finally return (apply #'+ (mapcar #'funcall funs)) )

Somehow, the code doesn't make any sense to me.  What it's supposed to
achieve?

>
> Any method?  I would like to test it with Emacs 31.  Would it make a

Where did you get "Emacs 31"?  ;)

> difference?
>
> Honestly: Do the cl-loop fans think we should change the behavior?
>
>
> Michael.
>
>

-- 
Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5
Fediverse: akib@hostux.social
Codeberg: akib
emailselfdefense.fsf.org | "Nothing can be secure without encryption."

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: cl-loop - do you understand it well?

[tomas]

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

On Sun, Dec 11, 2022 at 01:00:41AM +0600, Akib Azmain Turja wrote:
> Michael Heerdegen <michael_heerdegen@web.de> writes:

[...]

> > Any method?  I would like to test it with Emacs 31.  Would it make a
> 
> Where did you get "Emacs 31"?  ;)

Michael has an "Emacs Prime Time" subscription. They send packages from
the future :)

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: cl-loop - do you understand it well?

[Michael Heerdegen]

<tomas@tuxteam.de> writes:

> > Where did you get "Emacs 31"?  ;)
>
> Michael has an "Emacs Prime Time" subscription. They send packages from
> the future :)

Jokes aside: No. I'm just using a gv-setter of `current-time'.  I want
to see if it has any side effects before I'm going to install that
patch.  Maybe it's in Emacs 31, didn't check.

BTW, the implementation was a lot harder than expected but it was worth
it AFAICT.

Michael.

Re: cl-loop - do you understand it well?

[Akib Azmain Turja]

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

Michael Heerdegen <michael_heerdegen@web.de> writes:

> <tomas@tuxteam.de> writes:
>
>> > Where did you get "Emacs 31"?  ;)
>>
>> Michael has an "Emacs Prime Time" subscription. They send packages from
>> the future :)

:)  :)  :)

>
> Jokes aside: No. I'm just using a gv-setter of `current-time'.  I want

Is it something new?  How this will be useful?

> to see if it has any side effects before I'm going to install that
> patch.  Maybe it's in Emacs 31, didn't check.

Emacs 29 branch has been cut for release, so the master branch should
hold the upcoming Emacs 30, not Emacs 31.

Or do you plan to apply the patch on Emacs 31?

>
> BTW, the implementation was a lot harder than expected but it was worth
> it AFAICT.
>
> Michael.
>
>

-- 
Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5
Fediverse: akib@hostux.social
Codeberg: akib
emailselfdefense.fsf.org | "Nothing can be secure without encryption."

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: cl-loop - do you understand it well?

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

Akib Azmain Turja [2022-12-11 11:57:51] wrote:
> Michael Heerdegen <michael_heerdegen@web.de> writes:
>> <tomas@tuxteam.de> writes:
>>> > Where did you get "Emacs 31"?  ;)
>>> Michael has an "Emacs Prime Time" subscription. They send packages from
>>> the future :)
> :)  :)  :)
>> Jokes aside: No. I'm just using a gv-setter of `current-time'.  I want
> Is it something new?

"new" is relative.  It depends on what you have set (current-time).

> How this will be useful?

It will be useful for example to correct past mistakes.


        Stefan

Re: cl-loop - do you understand it well?

[Michael Heerdegen]

Akib Azmain Turja <akib@disroot.org> writes:

> > Jokes aside: No. I'm just using a gv-setter of `current-time'.  I want
>
> Is it something new?  How this will be useful?

It would be very useful but no I don't have such a thing, it was a
joke.

Michael.

Re: cl-loop - do you understand it well?

[Akib Azmain Turja]

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

Just yet another spam.  ;b

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

[...]

>> Is it something new?
>
> "new" is relative.  It depends on what you have set (current-time).
>
>> How this will be useful?
>
> It will be useful for example to correct past mistakes.

Then I must quote etc/future-bug:

--8<---------------cut here---------------start------------->8---
Date: Tue, 23 Feb 2199 21:03:50 -0600
From: Karl Fogel <kfogel@floss.cyclic.com>
To: bug-gnu-emacs@prep.ai.mit.edu
Subject: M-x search-backward-in-time broken...
X-Windows: you'll envy the dead.

In GNU Emacs 51.70.4 (i9986-unknown-linux-gnu, X toolkit) of Sat Feb  20 2199 on floss
configured using `configure  --with-x-toolkit=yes'

        The `search-backward-in-time' function appears to be broken in
Emacs 51.70.

        Unfortunately, I can never seem to start the debugger early
enough to catch the error as it happens.  However I have traced the
problem through source by eye, and it looks like `time-forward' can't
handle negative arguments anymore.  This is consistent with other
symptoms: for example, `undo' (which since 51.25 has worked by passing
a negative arg to `time-forward') is also broken.  However, `do' still
works -- it seems that `time-forward' continues to handle positive
arguments just fine.

        No one here-and-now can figure out how to fix the problem,
because the code for `time-forward' is so hairy.  We're using M-x
report-future-emacs-bug to request that you folks include more
comments when you write it (sometime in 2198 as I recall).

        Thanks!

-Karl Fogel   <kfogel@red-bean.com>


P.S. You'll be pleased to know that since (time-forward N) still works
     for N >= 0, we've used it to pre-emptively update configure.ac.
     Emacs now configures and builds on every platform that will ever
     be made.  It wasn't easy, but at least that's one problem out of
     the way for good.  If you'd like the patch, just ask.

--8<---------------cut here---------------end--------------->8---

I really wonder that English won't change it next 200 years.  :)
But the language model in my head broke while writing about something
that'll happen in time.  >D

The only problem is that observing the current rapid development speed,
I can say that we'll get Emacs 51 well before 2050, and it's unlikely to
ever have version 51.70.4 (we'll have 51.0.50, 51.1, 51.2, 51.3 and then
we'll jump to 52.0.50).  :)

And I'm really sad that we'll still have Intel processors, X Toolkit and
domain names in 22nd century.  :/

Oh and yes, I want the configure.ac patch.  How can I contact Karl Fogel
who is 177 years in future?  ;)

-- 
Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5
Fediverse: akib@hostux.social
Codeberg: akib
emailselfdefense.fsf.org | "Nothing can be secure without encryption."

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: cl-loop - do you understand it well?

[Emanuel Berg]

Michael Heerdegen wrote:

>>> Jokes aside: No. I'm just using a gv-setter of
>>> `current-time'. I want
>>
>> Is it something new? How this will be useful?
>
> It would be very useful but no I don't have such a thing, it
> was a joke.

Jokes that I don't understand aside, why does this return 4?

(require 'cl-lib)

(cl-loop
  for i from 0 to 1
  collect (lambda () i) into funs
  finally return (apply #'+ (mapcar #'funcall funs)) )

-- 
underground experts united
https://dataswamp.org/~incal

Re: cl-loop - do you understand it well?

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

> Jokes that I don't understand aside, why does this return 4?
>
> (require 'cl-lib)
>
> (cl-loop
>   for i from 0 to 1
>   collect (lambda () i) into funs
>   finally return (apply #'+ (mapcar #'funcall funs)) )

That's because you chose "0 to 1".
To get the *real* answer, you need to do "1 to 6", of course.


        Stefan

Re: cl-loop - do you understand it well?

[Michael Heerdegen]

Emanuel Berg <incal@dataswamp.org> writes:

> Jokes that I don't understand aside, why does this return 4?
>
> (require 'cl-lib)
>
> (cl-loop
>   for i from 0 to 1
>   collect (lambda () i) into funs
>   finally return (apply #'+ (mapcar #'funcall funs)) )

Because of internal implementation details?

Michael.

Re: cl-loop - do you understand it well?

[Emanuel Berg]

Stefan Monnier via Users list for the GNU Emacs text editor wrote:

>> (require 'cl-lib)
>>
>> (cl-loop
>>   for i from 0 to 1
>>   collect (lambda () i) into funs
>>   finally return (apply #'+ (mapcar #'funcall funs)) )
>
> That's because you chose "0 to 1". To get the *real* answer,
> you need to do "1 to 6", of course.

I don't have to check that ... 42.

-- 
underground experts united
https://dataswamp.org/~incal

Re: cl-loop - do you understand it well?

[Emanuel Berg]

Michael Heerdegen wrote:

>> Jokes that I don't understand aside, why does this return 4?
>>
>> (require 'cl-lib)
>>
>> (cl-loop
>>   for i from 0 to 1
>>   collect (lambda () i) into funs
>>   finally return (apply #'+ (mapcar #'funcall funs)) )
>
> Because of internal implementation details?

I don't think so, rather it has something to do with how
`cl-loop' is programmed.

-- 
underground experts united
https://dataswamp.org/~incal

Re: cl-loop - do you understand it well?

[Michael Heerdegen]

Emanuel Berg <incal@dataswamp.org> writes:

> >> Jokes that I don't understand aside, why does this return 4?
> >>
> >> (require 'cl-lib)
> >>
> >> (cl-loop
> >>   for i from 0 to 1
> >>   collect (lambda () i) into funs
> >>   finally return (apply #'+ (mapcar #'funcall funs)) )
> >
> > Because of internal implementation details?
>
> I don't think so, rather it has something to do with how
> `cl-loop' is programmed.

This was a joke, right?

Anyway,

#+begin_src emacs-lisp
(macroexpand-1
 '(cl-loop
   for i from 0 to 1
   collect (lambda () i) into funs
   finally return (apply #'+ (mapcar #'funcall funs))))
  ==>
  (cl-block nil
    (let* ((i 0)
           (funs nil))
      (while (<= i 1)
        (setq funs (nconc funs (list (lambda nil i))))
        (setq i (+ i 1)))
      (apply #'+ (mapcar #'funcall funs))))
#+end_src

Nearly the same code as we had discussed.  But I guess this was all
clear to you (or not?).

Michael.

Re: cl-loop - do you understand it well?

[Emanuel Berg]

Michael Heerdegen wrote:

>   (cl-block nil
>     (let* ((i 0)
>            (funs nil))
>       (while (<= i 1)
>         (setq funs (nconc funs (list (lambda nil i))))
>         (setq i (+ i 1)))
>       (apply #'+ (mapcar #'funcall funs))))
>
> Nearly the same code as we had discussed. But I guess this
> was all clear to you (or not?).

No, where does the 4 come from?

-- 
underground experts united
https://dataswamp.org/~incal

Re: cl-loop - do you understand it well?

[Michael Heerdegen]

Emanuel Berg <incal@dataswamp.org> writes:

> >   (cl-block nil
> >     (let* ((i 0)
> >            (funs nil))
> >       (while (<= i 1)
> >         (setq funs (nconc funs (list (lambda nil i))))
> >         (setq i (+ i 1)))
> >       (apply #'+ (mapcar #'funcall funs))))
> >
> No, where does the 4 come from?

There are two closures in FUNS, and both share the same lexical variable
i.  When the closures are `funcall'ed i is bound to 2, which is the
value i had when the loop is exited.  2*2=4.

The goal of this exercise was to demonstrate that closures share
modifiable environments instead of copies of values present at closure
creation time.

Michael.