On Fri, 7 Apr 2017, Drew Adams wrote:
>>> Or an addition to cl-loop that would allow doing something like
>>>
>>> (cl-loop for m being the matches of "foo\\|bar"
>>> do ...)
>>>
>>> Then you could easily 'collect m' to get the list of matches if you want
>>> that.
>>
>> Your proposals looks nice to me ;-)
>
> (Caveat: I have not been following this thread.)
>
> I think that `cl-loop' should be as close to Common Lisp `loop'
> as we can reasonably make it. We should _not_ be adding other
> features to it or changing its behavior away from what it is
> supposedly emulating.
>
> If you want, create a _different_ macro that is Emacs-specific,
> with whatever behavior you want. Call it whatever you want
> that will not be confused with Common Lisp emulation.
>
> Please keep `cl-' for Common Lisp emulation. We've already
> seen more than enough tampering with this - people adding
> their favorite thing to the `cl-' namespace. Not good.
Drew, i respect your opinion; but so far the change
would just extend `cl-loop' which as you noticed has being already
extended before.
For instance, we have:
cl-loop for x being the overlays/buffers ...
Don't see a problem to have those things.
I do. They couple the idea of an iterable with a looping construct, and such coupling is bad for various reasons:
- Coupling of unrelated entities is always an antipattern.
- For N iterables and M looping constructs, you need to implement N*M integrations.
Instead this should use an iterable, e.g. a generator function (iter-defun). cl-loop supports these out of the box.