From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: okamsn--- via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#70524: [PATCH] Fix `map-elt` with `setf` for subplaces Date: Mon, 29 Apr 2024 01:08:42 +0000 Message-ID: References: <87a5lji9bg.fsf@web.de> <9a68b4fc-55ee-41fc-aa2c-c69e9498aff0@protonmail.com> <878r10xqnd.fsf@web.de> Reply-To: okamsn@protonmail.com Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30442"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Stefan Monnier , 70524@debbugs.gnu.org To: Michael Heerdegen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Apr 29 03:10:00 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1s1FWq-0007gT-Q6 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 29 Apr 2024 03:10:00 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s1FWa-0000X6-8X; Sun, 28 Apr 2024 21:09:44 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s1FWY-0000Ur-Qc for bug-gnu-emacs@gnu.org; Sun, 28 Apr 2024 21:09:42 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1s1FWY-0007Yi-IF for bug-gnu-emacs@gnu.org; Sun, 28 Apr 2024 21:09:42 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1s1FWs-0007pX-7m for bug-gnu-emacs@gnu.org; Sun, 28 Apr 2024 21:10:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: okamsn@protonmail.com Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 29 Apr 2024 01:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 70524 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 70524-submit@debbugs.gnu.org id=B70524.171435295630070 (code B ref 70524); Mon, 29 Apr 2024 01:10:02 +0000 Original-Received: (at 70524) by debbugs.gnu.org; 29 Apr 2024 01:09:16 +0000 Original-Received: from localhost ([127.0.0.1]:53920 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s1FW7-0007ow-RL for submit@debbugs.gnu.org; Sun, 28 Apr 2024 21:09:16 -0400 Original-Received: from mail-4316.protonmail.ch ([185.70.43.16]:59203) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s1FW5-0007oo-EF for 70524@debbugs.gnu.org; Sun, 28 Apr 2024 21:09:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1714352927; x=1714612127; bh=hMzC//1Jlzmr2HkPfTVQEr5fkeZzWBe+om6KZuYtEJ8=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=g6Crhbwh247K/otAxX5U1FesbWmYVx/RaextFFQ26Wxvl8fmg+QGvwgGYz/yotNUg jLfT2sofpfLHGadn7S45S4BAy1QYN5kEVVq5bYqmyO3+PucGNgYnIrsT4UgfG9gL0e LBCu2Yhm+N2s88q1a48mGrY/LHUJmwGRCkecjQLCLb4OxPaPD9xRBQEEIGiGQ5QJOG aPFKQd27BAjqUULog7NkYgIa4m8kATpY7VYetsuXYwV0Gecclr0bZD555d/4jMLyPt KFncVIcoVOoJJaGpDXzTOfBrJBm64h1KMJ6YsdcDDu/X4wR7pD/UsRjl0rSOReDSsR 0dspHMFVlQcjg== In-Reply-To: <878r10xqnd.fsf@web.de> Feedback-ID: 25935600:user:proton X-Pm-Message-ID: 7ec704f7e374ef270ec13c51fbc94d8ac9b4c341 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:284113 Archived-At: Michael Heerdegen wrote: > okamsn@protonmail.com writes: >=20 >> My purpose with this patch and for bug#68863 regarding `seq-subseq` >> (which does not currently support `setf`, and I think should allow >> subplaces like `substring` claims to) >=20 > The `substring' gv-setter doesn't need a loop however, it creates a new > string using `concat'. Your patch would probably "work" ok in this > case, but I'm not convinced that this would be an improvement, still for > the same reasons. >=20 >> was for destructuring as `setf`-able places, like in cl-loop's `for >> VAR in-ref LIST`. I have implemented that for my Emacs Lisp package >> (https://github.com/okamsn/loopy), but not all of the `setf`-able >> destructuring constructs support sub-places in the expected way, due >> to how some of the GV expansions are defined. >=20 > But if loopy would base on an inefficient implementations this would not > be useful. >=20 > Are there examples where your patch is really a clear improvement? Hello, I have found cases in Loopy where I am using `(setf (map-elt (map-elt=20 ...))` and similar. From what you and others have said, it sounds like=20 this luckily happened to work but should not have been relied upon. I=20 have now seen the thread bug#62068 about `map-nested-elt` mentioned by=20 Augusto Stoffel, and I agree with the thoughts there that an improvement=20 can be made for that use case. That could be having `map-elt` support=20 sub-places in general, or it could be having `map-nested-elt` be a=20 generalized variable to support the one case. On efficiency and maybe outside of the sub-place question, I used=20 `seq-map` because I thought that it would be a good way to make sure=20 that the generic sequence was only moved through once. For a=20 hypothetical `seq-replace`, do you think it would be better to use a=20 combination `seq-concat`, `seq-take`, and `seq-subseq` and to assume=20 that they are efficient implementations for the generic version? Do you=20 think that it would be better if there were different implementations=20 for each combination of the built-in sequence types, like the checks=20 `cl-replace` has for lists and arrays? Thank you. >=20 > Michael.