From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Juanma Barranquero Newsgroups: gmane.emacs.devel Subject: Re: master f225011: ibuffer-do-isearch: don't depend on `cl-values-list' (bug#38430) Date: Mon, 2 Dec 2019 03:20:31 +0100 Message-ID: References: <20191201091356.26612.95511@vcs0.savannah.gnu.org> <20191201091358.11752207E0@vcs0.savannah.gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000689a830598af3b51" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="3994"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Emacs developers To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 02 03:21:19 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1ibbKx-0000vx-FR for ged-emacs-devel@m.gmane.org; Mon, 02 Dec 2019 03:21:19 +0100 Original-Received: from localhost ([::1]:57992 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ibbKv-0003RW-JH for ged-emacs-devel@m.gmane.org; Sun, 01 Dec 2019 21:21:17 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58634) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ibbKn-0003Pi-IW for emacs-devel@gnu.org; Sun, 01 Dec 2019 21:21:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ibbKl-0004Id-QM for emacs-devel@gnu.org; Sun, 01 Dec 2019 21:21:09 -0500 Original-Received: from mail-qv1-xf29.google.com ([2607:f8b0:4864:20::f29]:45149) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ibbKl-0004IP-Jq for emacs-devel@gnu.org; Sun, 01 Dec 2019 21:21:07 -0500 Original-Received: by mail-qv1-xf29.google.com with SMTP id c2so6642517qvp.12 for ; Sun, 01 Dec 2019 18:21:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uoU5pak+OJTyxmpeRBY7OlBhXlJ5SqSogBAWHlf+G0c=; b=fa8kHNtWaY6gkkMqdn6wJJg0+aRM+drZntBIc2AhoGvAdfH4mMV3NWoKUJE7dWp3Fy Jo99H40NMbNLl8xIal6k2po2t99q3lfUQIml0y8qsyXHmPONvEPiVM4UbjG77Zl1s8r8 hph6Y4ZSHy+eHx+tTYS4+VVUEak3ZOIe4ptJy5u0bmX42gm5taWXDdi3jT95zGtFHQwJ rnp4fKbNr+AfgThudYwpbrBMR0BVwQF2T41iyr3EsT3pghq6N/iLOAZLq9sA6MUwuPJi c3DpX3kLkSkoGxS67HdJ14bQmdZl2+KVltjfLZqYMW7F4NlM/B29VJPah0RB73oP20tp t8yA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uoU5pak+OJTyxmpeRBY7OlBhXlJ5SqSogBAWHlf+G0c=; b=B+oz0bduMUw1E2vUBeN8zVtx7IsaF03sP+OXpPoQodFpphZnFwXURKDEqX0QfuZ+xy FQb78StkbmWU+sXjk3fykUpZXE4/qPq2xwa3gNJoW66WzEXwctcYjkVOEVbJyLOmlVbG 5EHhkLva/kxleaqJGWaBN8pPsQAGVfZTOVWxOqIqGMv2oJm/K4QycmSrp94e1AfYJUdj tcgzJHIhIBKrghnNsO/M/9e5FLkJdVHbyBBu0InlW8NXiU7zNy5F7ukdR6iofdVGLGn8 WF/KXImQjIrj1h8qcJWiZco2/qN+iQLa9Kkfi5gWjYo+elEktweNa9KMDNuAslKb7QXF okFw== X-Gm-Message-State: APjAAAV56a8ouiqCVqC8x48cyydv6mrIKciMIseJ3G9LL1O/SFLjdDBo oX9wjd7QCchN+6vrwZo5jWB16PgW3SpC4FGRkZE= X-Google-Smtp-Source: APXvYqwax392SQXlcVH48+LLix2+OXPcQ9qL8ILDSfcfVP09rAv5sr9VD+lkbvo/YvjMBdNna7vsJPMtB8jNRE8GWsU= X-Received: by 2002:ad4:450a:: with SMTP id k10mr29226122qvu.136.1575253266961; Sun, 01 Dec 2019 18:21:06 -0800 (PST) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::f29 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:242983 Archived-At: --000000000000689a830598af3b51 Content-Type: text/plain; charset="UTF-8" On Mon, Dec 2, 2019 at 2:55 AM Stefan Monnier wrote: > I must admit I'm biased: I find c-lib's multiple-value support to be > completely worthless. I don't know anything you can do with that you > can't do just as easily without it. IOW it only makes sense as > a "compatibility with Common-Lisp", yet it doesn't provide the right > semantics either so it doesn't work for that either. > > I regret not having noticed it back in Emacs-24 time when I could have > marked those functions as obsolete (or even kept them in cl.el but not > in cl-lib.el). I think we should mark them as obsolete and work to remove them some day. They add clutter with no real benefit. It's silly to have compatibility with such a feature while we aren't compatible with other useful features of Common Lisp, like namespaces (I mean, "packages") or format. > I consider the patch you showed as broken (regardless of whether it > does work in practice, obviously). Require cl-lib is another way to fix > this, if you want a less intrusive patch. I've commited a fix with cl-destructuring-bind. This is a case where cl functions (cl-multiple-value-bind and cl-values-list) didn't add anything of value (no pun intended). Once we branch, we could perhaps try using more cl and not less. Not just in that case, but using cl functions instead of reimplementing them here and there. I mean, (ibuffer-remove-alist 'key alist) == (cl-remove 'key alist :key #'car) and ibuffer-remove-duplicates is just a reimplementation of cl-remove-duplicates, without the bells and whistles. *But*, I think we should have in place a definite policy about cl-lib. --000000000000689a830598af3b51 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Dec 2, 2019 at 2:55 AM St= efan Monnier <monnier@iro.um= ontreal.ca> wrote:

> = I must admit I'm biased: I find c-lib's multiple-value support to b= e
> completely worthless.=C2=A0 I don't know anything you can do = with that you
> can't do just as easily without it.=C2=A0 IOW it = only makes sense as
> a "compatibility with Common-Lisp", y= et it doesn't provide the right
> semantics either so it doesn= 9;t work for that either.
>
> I regret not having noticed it ba= ck in Emacs-24 time when I could have
> marked those functions as obs= olete (or even kept them in cl.el but not
> in cl-lib.el).

I think we should mark them as obso= lete=C2=A0and work to remove them some day.
They add clutter with no real benefit. It's silly to have co= mpatibility
with such a feature w= hile we aren't compatible with other useful features
<= font face=3D"monospace">of Common Lisp, like namespaces (I mean, "pack= ages") or format.

> I consider the patch you showed a= s broken (regardless of whether it
> does work in practice, obviously= ).=C2=A0 Require cl-lib is another way to fix
> this, if you want a l= ess intrusive patch.

<= /div>
I've commited a fix with cl-destruct= uring-bind. This is a case where cl
functions (cl-multiple-value-bind and cl-values-list) didn't add any= thing
of value (no pun intended).=

Once we branch, we could perhaps try using more cl and not less. No= t just
in that case, but using cl= functions instead of reimplementing them here
and there.

I mean,

=C2=A0 (ibuff= er-remove-alist 'key alist) =3D=3D (cl-remove 'key alist :key #'= ;car)

and ibuffer-remove-duplicates is just a reimplementatio= n of
cl-remove-duplicates, withou= t the bells and whistles.

*But*, I think we should have in pl= ace a definite policy about cl-lib.

--000000000000689a830598af3b51--