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: Thu, 25 Apr 2024 01:59:36 +0000 Message-ID: <9a68b4fc-55ee-41fc-aa2c-c69e9498aff0@protonmail.com> References: <87a5lji9bg.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="16755"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 70524@debbugs.gnu.org To: Stefan Monnier , Michael Heerdegen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Apr 25 04:01:18 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 1rzoQH-0004BV-M3 for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 25 Apr 2024 04:01:17 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rzoPw-0004g2-Ie; Wed, 24 Apr 2024 22:00:56 -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 1rzoPt-0004fm-Ka for bug-gnu-emacs@gnu.org; Wed, 24 Apr 2024 22:00:53 -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 1rzoPt-0005M2-C7 for bug-gnu-emacs@gnu.org; Wed, 24 Apr 2024 22:00:53 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rzoQA-0003RZ-5E for bug-gnu-emacs@gnu.org; Wed, 24 Apr 2024 22:01:10 -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: Thu, 25 Apr 2024 02:01:09 +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.171401041712653 (code B ref 70524); Thu, 25 Apr 2024 02:01:09 +0000 Original-Received: (at 70524) by debbugs.gnu.org; 25 Apr 2024 02:00:17 +0000 Original-Received: from localhost ([127.0.0.1]:60273 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rzoPE-0003HP-RL for submit@debbugs.gnu.org; Wed, 24 Apr 2024 22:00:15 -0400 Original-Received: from mail-4322.protonmail.ch ([185.70.43.22]:29915) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rzoP8-0003FL-Tf for 70524@debbugs.gnu.org; Wed, 24 Apr 2024 22:00:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1714010383; x=1714269583; bh=gpq0tZejurU5VBZIRPl5y1aXynrFEDaOfQxOsAWDEx0=; 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=r8gLVJNbd12hgWHNOYVTLol/44MSleSbI05U4+vNhAoHrWAucklNVX/dXeT1ASOpn xA7JWTTlMWUDmPZ6jJUBFYWUDbHAmoSQCpU9HGk8NXraq1XkHOsDiugYnq5VQBs0VY il88RShyb2HyLM7aQBNM85sKTPs2+F5AsSiVGkrIMij+x+h1QYCEnjRjpgCDisCgUy xngsbS7oTE2GEox9lSmD2dNlevXSq5ksm91AJFUNEnu6/7wthE6CLe5iyDWTxBDq0J AxiP47JHNaJxhbcdcB7GUh1ZTdW/V6ycIuMbDdvjNnAyDc6ChHEPuP7OvTPsaaSiyb T34wZ81UiYMTQ== In-Reply-To: Feedback-ID: 25935600:user:proton X-Pm-Message-ID: b2656217444eb7f8c8302f163620b21840e35230 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:283935 Archived-At: Stefan Monnier wrote: >>> Currently, the use >>> >>> (let ((arr (vector 0 1 2 3 4 5 6))) >>> (setf (map-elt (cl-subseq arr 3) 0) >>> 27) >>> arr) >>> >>> expands to [...] >> >> But... I must admit I'm not really convinced that this has to be >> changed. >=20 > I'm also unconvinced. AFAICT the same problem occurs with >=20 > (setf (aref (cl-subseq arr 3) 0) 27) >=20 > and I can't think of a good reason why `map-elt` should behave differentl= y. I would have assumed that `aref` would work with subplaces. I am still=20 thinking of `setf` like a more flexible version of Python allowing=20 things like `my_list[0][0] =3D 27`. > Furthermore, the change would also fundamentally change the way > `map-elt` can be used as a gv-place, in the sense that >=20 > (setf (map-elt (funcall foo bar) 0) 27) >=20 > would signal an error during macroexpansion because (funcall foo bar) > is not a valid gv-place. I am trying to come up with an example that triggers the second path=20 using `map-insert` in the examples that I sent. In the second path, the=20 current version of the `map-elt` setter will already correctly set the=20 subplace using `cl-replace`. I am trying to find an example where the=20 inconsistency makes a difference. My purpose with this patch and for bug#68863 regarding `seq-subseq`=20 (which does not currently support `setf`, and I think should allow=20 subplaces like `substring` claims to) was for destructuring as=20 `setf`-able places, like in cl-loop's `for VAR in-ref LIST`. I have=20 implemented that for my Emacs Lisp package=20 (https://github.com/okamsn/loopy), but not all of the `setf`-able=20 destructuring constructs support sub-places in the expected way, due to=20 how some of the GV expansions are defined. I did not consider calling=20 `setf` on a function's output. For example, with the two patches, one can do ;; =3D> (1 2 [29 99] 29) (let ((arr (vector 1 2 88 99))) (loopy-ref (([a b &rest [&whole c &map (0 map-idx-0)]] arr)) (setf map-idx-0 29) (list a b c map-idx-0))) and have the `setf`-able destructuring work as expected. >> But second - doesn't your patch lead to very inefficient code in this >> example, where nearly all elements of the original sequence get replace= d >> by themselves in a loop (through the setter of `cl-subseq')? > > Yes, that's another issue. I think if wvale want to support such=20 `setf` in > a way that is good enough to that we can recommend its use, we'd need to > turn it into something that behaves more or less like: > val > (map-set! arr (+ 3 0) 27) > > But I must admit that I don't know how to get there. This is true. I could have used `setf (map-elt (cl-subseq arr 3 4) 0)=20 27)` to be more efficient. Thank you.