Re: Any interest in a function like this to add to subr.el?

[John Wiegley <jwiegley@gmail.com>]

>>>>> Ken Raeburn <raeburn@raeburn.org> 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