GNU bug report logs -
#70524
[PATCH] Fix `map-elt` with `setf` for subplaces
Previous Next
Reported by: Okamsn <okamsn <at> protonmail.com>
Date: Tue, 23 Apr 2024 02:12:03 UTC
Severity: normal
Tags: patch
Done: Michael Heerdegen <michael_heerdegen <at> web.de>
Bug is archived. No further changes may be made.
Full log
Message #14 received at 70524 <at> debbugs.gnu.org (full text, mbox):
>> 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.
I'm also unconvinced. AFAICT the same problem occurs with
(setf (aref (cl-subseq arr 3) 0) 27)
and I can't think of a good reason why `map-elt` should behave differently.
Furthermore, the change would also fundamentally change the way
`map-elt` can be used as a gv-place, in the sense that
(setf (map-elt (funcall foo bar) 0) 27)
would signal an error during macroexpansion because (funcall foo bar)
is not a valid gv-place.
> But second - doesn't your patch lead to very inefficient code in this
> example, where nearly all elements of the original sequence get replaced
> by themselves in a loop (through the setter of `cl-subseq')?
Yes, that's another issue. I think if we want to support such `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:
(map-set! arr (+ 3 0) 27)
But I must admit that I don't know how to get there.
Stefan
This bug report was last modified 1 year and 17 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.