[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Any interest in a function like this to add to subr.el?
From: |
John Wiegley |
Subject: |
Re: Any interest in a function like this to add to subr.el? |
Date: |
Tue, 18 Oct 2016 23:02:22 -0700 |
User-agent: |
Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.1.50 (darwin) |
>>>>> Ken Raeburn <address@hidden> writes:
> Is there a shorthand function for this bit? I.e., mutate every element of
> the list according to some supplied function, but reusing the same list
> storage. If so, the body of sort-on* becomes about as short as your original
> sort-on.
I'd like that too.
> Is there any benefit to sort* instead of sort here? As far as I can see,
> sort* just calls sort after (1) checking whether the list we just iterated
> over is a list, and (2) checking whether we supplied a “:key” keyword, which
> we didn’t.
You're right, I should just use sort.
> “sort” and “sort*” will work on vectors, too, returning the now-sorted
> vector; your sort-on, using mapcar, will make it into a list, and sort-on*
> will fail trying to apply car and cdr to vectors. Were these intended to
> work on lists only?
It should be generalized to work for vectors as well.
> As far as your doc strings go, you say sort-on will apply the accessor “at
> most once per element in the list”, but it’s going to be exactly once per
> element, isn’t it?
Correct.
> The “cdr” pass before returning could walk the intermediate sorted list in
> the sort-on case too, making it more space-efficient. Since the inner
> “mapcar” call has allocated us some unshared storage, we can just alter it
> in place and return it to the caller.
Great observation, I'll do that!
Thanks for the valuable feedback,
--
John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2
Re: Any interest in a function like this to add to subr.el?, Andy Moreton, 2016/10/19