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 <anthony.d.clayden@gmail.com> wrote:
> On 24 Mar 2023, at 18:44, Johannes Waldmann <johannes.waldmann at htwk-leipzig.de> 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.