all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Tino Calancha <tino.calancha@gmail.com>
Cc: 26338@debbugs.gnu.org, npostavs@users.sourceforge.net,
	Marcin Borkowski <mbork@mbork.pl>, Juri Linkov <juri@linkov.net>
Subject: bug#26338: 26.0.50; Collect all matches for REGEXP in current buffer
Date: Fri, 7 Apr 2017 22:49:29 -0700 (PDT)	[thread overview]
Message-ID: <e63f6c64-fe5e-4470-aa78-1bbe67020cfa@default> (raw)
In-Reply-To: <alpine.DEB.2.20.1704081338250.3238@calancha-pc>

> >>> 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.  We already point out in the
> manual that these are Emacs specific things, so nobody should be fooled
> with that.  As far as we cover all CL clauses, what problem could be in
> having a few more?

You make a fair point when you stick to only extension and
keep compatibility for the rest.  I still disagree with it,
for the reasons given below.

And because the next enhancement proposal will perhaps just
point to this one as more precedent for making changes,
without bothering to, itself, ensure that "we cover all CL
clauses" etc.  As you pointed out: "so far"...  Little by
little, we've already seen `cl-' diluted from CL by being
incrementally "enhanced".

Here's my general opinion on this kind of thing:

I agree that such things are useful.  I have nothing against
them, and I'm glad to see Emacs have them.  My objection is
to using `cl-loop' for it.

`cl-loop' - and all of the stuff in `cl-*' - should be for
Common Lisp emulation.  Nothing more or less.  That's my
opinion.

Emacs should have its _own_, non-cl-* functions, macros,
variables, whatever.  It can take Common Lisp constructs
as a point of departure or inspiration, and extend enhance,
limit, or in any way change that point of departure as is
most fitting and useful for Emacs.

That's normal.  I'm all for that kind of thing.  But it
should not be confused with Common Lisp emulation.  `cl-'
should be kept for Common Lisp emulation.

Users should be able to recognize when they are using CL
code (an emulation of it).  Users should be able to take
existing CL code and use it in Emacs with little or no
modification (no, we're not there yet, and never will be
completely, but it's a good goal).

Put all this stuff - and more - into an `eloop' macro.
Since it will be so much better and more Emacsy, with
specifics that are especially useful for Emacs, it is
what users will (eventually) use instead of `cl-loop'.

Since it will do everything that `cl-loop' does (and
more), eventually only the rare user who needs, or for
some reason really wants, code that is CL or close to
it will use `cl-loop'.  Everyone else will use `eloop'.
No problem.

I am sure that my opinion on this is a minority one -
perhaps a minority of one.

But going the other direction, along lines such as what
you suggest:

1. We lose the value of `cl-' as an emulation of CL.  And
   typically we lose compatibility with existing CL code.

2. We lose the ability, when seeing something `cl-', to
   know we can look it up in the (fine) Common Lisp docs.

3. Where does it stop?  What's the point of `cl-', if
   anything goes and we can stuff whatever into it?

What prevents Emacs design from doing the right thing?
What do we lose by putting non-CL stuff into an `eloop'
that extends `cl-loop' in Emacsy ways?

Sure, invent more and better and different.  But put it
in a different namespace or in no namespace.

If `cl-' is just an Emacs thing and no longer a Common
Lisp thing then why the pretense of having a CL manual;
and using a `cl-' namespace; and pointing to the CL docs
for explanation (the Emacs docs explain practically
nothing about its `cl-' constructs - there is really no
doc for `cl-' in Emacs)?

What's the point?  Leave `cl-loop' as Common Lisp's `loop'.
Create a more-and-better, more Emacsy `eloop' or whatever.
Complete freedom - do whatever.  My vote is only that `cl-'
be kept for CL (and even be cleaned up to be more like it).





  reply	other threads:[~2017-04-08  5:49 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-02 12:41 bug#26338: 26.0.50; Collect all matches for REGEXP in current buffer Tino Calancha
2017-04-02 15:57 ` Dmitry Gutov
2017-04-03  3:58   ` Tino Calancha
2017-04-02 22:10 ` Juri Linkov
2017-04-03  4:01   ` Tino Calancha
2017-04-03  6:13   ` Tino Calancha
2017-04-03 23:35     ` Juri Linkov
2017-04-04  1:37       ` Tino Calancha
2017-04-04  2:20         ` Tino Calancha
2017-04-04 14:32         ` Marcin Borkowski
2017-04-05 11:58           ` Tino Calancha
2017-04-05 13:11             ` npostavs
2017-04-07 10:06               ` Tino Calancha
2017-04-07 14:40                 ` Drew Adams
2017-04-08  4:45                   ` Tino Calancha
2017-04-08  5:49                     ` Drew Adams [this message]
2017-04-08 15:29                       ` Tino Calancha
2017-04-08 15:42                         ` Drew Adams
2017-04-08 11:46                     ` Philipp Stephani
2017-04-08 13:42                       ` Tino Calancha
2017-04-08 14:41                         ` Philipp Stephani
2017-04-08 15:20                           ` Tino Calancha
2017-04-22 19:42                             ` Philipp Stephani
2017-04-08 15:38                           ` npostavs
2017-04-22 19:36                             ` Philipp Stephani
2017-04-05 22:03             ` Juri Linkov
2017-04-07 14:47               ` Tino Calancha
2017-04-07 15:28                 ` Noam Postavsky
2017-04-07 15:54                   ` Drew Adams
2017-04-08 13:49                   ` Tino Calancha
2020-09-15 15:41 ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e63f6c64-fe5e-4470-aa78-1bbe67020cfa@default \
    --to=drew.adams@oracle.com \
    --cc=26338@debbugs.gnu.org \
    --cc=juri@linkov.net \
    --cc=mbork@mbork.pl \
    --cc=npostavs@users.sourceforge.net \
    --cc=tino.calancha@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.