Email list hosting service & mailing list manager

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! Alex Shinn (12 Mar 2016 23:36 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