GNU bug report logs -
#26338
26.0.50; Collect all matches for REGEXP in current buffer
Previous Next
Reported by: Tino Calancha <tino.calancha <at> gmail.com>
Date: Sun, 2 Apr 2017 12:42:01 UTC
Severity: wishlist
Tags: wontfix
Found in version 26.0.50
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
Full log
Message #74 received at 26338 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Tino Calancha <tino.calancha <at> gmail.com> schrieb am Sa., 8. Apr. 2017 um
15:42 Uhr:
>
>
> On Sat, 8 Apr 2017, Philipp Stephani wrote:
>
> >
> >
> > Tino Calancha <tino.calancha <at> gmail.com> schrieb am Sa., 8. Apr. 2017 um
> 06:46 Uhr:
> >
> >
> > 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.
> Then, you don't like (as Drew, but for different reasons) that we have:
> cl-loop for x being the buffers ...
>
I don't like it, but it's there and cannot be removed for compatibility
reasons, so I'm not arguing about it. I'm arguing against adding more such
one-off forms.
>
> but it seems you are fine having iter-by clause in cl-loop, which seems an
> Emacs extension (correctme if i am wrong). So in principle, you are happy
> with adding useful extensions to CL, not just keep it an emulation as
> Drew wants.
>
Yes, I don't care about Common Lisp. The iter-by clause is less of a
problem than 'buffers' etc. because it's not a one-off that couples a
looping construct with some random semantics.
>
> Your point is about performance.
No, I care mostly about clarity, simplicity, and good API design, including
separation of concerns.
> I am driven by easy to write code.
> Maybe you can provide an example about how to write those things using
> the iter-by cl-loop clause.
Sure:
(require 'generator)
(iter-defun re-matches (regexp)
(while (re-search-forward regexp nil t)
(iter-yield (match-string 0))))
(iter-do (m (re-matches (rx digit)))
(print m))
(cl-loop for m iter-by (re-matches (rx digit))
do (print m))
[Message part 2 (text/html, inline)]
This bug report was last modified 4 years and 250 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.