there is no correct way to use list-sort! or list-stable-sort!
William D Clinger
(09 Mar 2016 12:31 UTC)
|
more corrections for SRFI 132
William D Clinger
(10 Mar 2016 17:06 UTC)
|
Re: more corrections for SRFI 132
William D Clinger
(10 Mar 2016 19:37 UTC)
|
Re: more corrections for SRFI 132
William D Clinger
(10 Mar 2016 20:32 UTC)
|
benchmarking the SRFI 132 reference implementation
William D Clinger
(10 Mar 2016 23:20 UTC)
|
Re: more corrections for SRFI 132
William D Clinger
(12 Mar 2016 03:07 UTC)
|
Re: more corrections for SRFI 132
Alex Shinn
(12 Mar 2016 23:26 UTC)
|
Re: more corrections for SRFI 132
John Cowan
(13 Mar 2016 22:02 UTC)
|
Re: there is no correct way to use list-sort! or list-stable-sort!
Kevin Wortman
(11 Mar 2016 19:44 UTC)
|
Re: there is no correct way to use list-sort! or list-stable-sort!
John Cowan
(13 Mar 2016 06:15 UTC)
|
Re: there is no correct way to use list-sort! or list-stable-sort! Alex Shinn (12 Mar 2016 23:36 UTC)
|
Re: there is no correct way to use list-sort! or list-stable-sort!
John Cowan
(13 Mar 2016 05:47 UTC)
|
Re: there is no correct way to use list-sort! or list-stable-sort! Alex Shinn 12 Mar 2016 23:36 UTC
On Wed, Mar 9, 2016 at 9:31 PM, William D Clinger <xxxxxx@ccs.neu.edu> wrote: > > So long as I'm commenting on SRFI 132, let me state my opinion that its > emphasis upon destructive operations is antiquated. With generational > garbage collectors, it's entirely possible that each of the destructive > operations allocates a transaction record needed to preserve invariants > that allow garbage to be collected without scanning the entire heap. > (Some generational collectors pre-allocate the storage needed for that > meta-data, while some allocate it on the fly.) The SRFI's claim that > destructive versions will run in constant space is therefore an empty > promise. As a counter-point, working with data-structures larger than the remaining free memory is not such a rare thing, and being able to sort them can be a nice feature. Linear update allows this as an implementation possibility. The current semantics, as you note, are simply broken. -- Alex