Twan van Laarhoven
Almost all uses of sortBy in user code use 'comparing', 'on' or a similar construction [1].
I certainly agree that there is room for improvement here. But I hate to see the proliferation of functions, almost all alike. I guess I would support the proposal if that's the way folks would like to go, though. I would prefer: 1) Get rid of any need for Data.Function by exporting 'fix' and 'on' into the Prelude. The rest of it is already in the Prelude anyway, and the implementations of 'fix' and 'on' are trivial. (I'd say Data.Function is kind of a failed experiment at this point, but what do I know?) 2) Move the sort functions into Data.Ord. Obviously, they would have to be re-exported by Data.List. It seems to me that 'sort' should have been there in the first place, and that 'sortBy" should be in the same place as 'sort'. 3) Incorporate the 'Down' (Is 'Descending' too long?) type in Data.Ord as suggested (but see below). Now Data.Ord would be the one-stop shopping place for all our sorting needs. If all of this were done, I really wouldn't mind importing Data.Ord to get the sorting functions and continuing to write 'sortBy (comparing f)' or 'sortBy (p `on` f)' when I wanted to do such a thing. Even 'sortBy (comparing Down `on` f)' isn't so bad. Minor nits in the proposal: * You need to implement either (<=) or `comparing` for Down (preferably `comparing`), not just (<). Otherwise sort nonterminates with a stack overflow. This one took me a while to figure out. As far as I can tell you'll need to make Down an instance of Eq as well as Ord to get the latter instance to typecheck. These problems suggest that you haven't yet tried your proposal at all. :-) :-) * getDown might better be called fromDown? Bart Massey bart <at> cs.pdx.edu