The correctness argument he was referring to was about understanding code
in an educational context. The relevance is that Data.List.sort breaks up
the input list into maximal "runs" of ascending or descending elements, to
take advantage of any pre-existing organization. It then merges up runs
rather than individual elements.
On Fri, Mar 24, 2023, 5:12 PM Anthony Clayden
* On 24 Mar 2023, at 18:44, Johannes Waldmann
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe> wrote: *> >* ... *>* Does the implementation in Data.List do better? *> Data.List's sort is doing a different thing. So I'm not seeing the relevance. Specifically, sort doesn't pay any attention to the incoming list's ordering.
* Since this is about "exercise" - I would expect my students *>* to find that code, so perhaps I'd point them to it right away, *>* and give the task to "understand it" (= argue that it is correct). *>* Arguing about cost seems harder. *>
This (ex-)student would wonder why you'd sent me to that code. (Perhaps the lesson is: first read the question.)
Why does the correctness (or otherwise) of a sort bear any relation to preserving list sequence and chopping up a list into ascending sublists?
AntC
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.