On Wed, Jan 7, 2015 at 5:08 PM, Keean Schupke <[email protected]> wrote: > Hmm, i'm not sure I agree... > > On 8 January 2015 at 00:53, Jonathan S. Shapiro <[email protected]> wrote: >> >> On Wed, Jan 7, 2015 at 4:08 PM, Keean Schupke <[email protected]> wrote: >>> >>> SortBy should not exist. By defining sort on a partial order, there is >>> only one sort direction. >> >> >> That's clearly false, because there can be multiple partial orders for any >> given set. You are arguing in circles here. > > > We only need to consider one partial order which is '<', maybe I need a > different terminology for this? > >> >> >> The pragmatic problem with sortBy is that it's performance absolutely >> sucks at types close to ground. That's why it's so important to have a way >> to explicitly inline the ordering operation. > > > My proposal would inline as it uses type-classes > >> >> >> The thing that's actually interesting about the sort example is that for >> many cases we do NOT want to inline the operator, because after you handle a >> certain number of specializations you don't want the code explosion of >> specializing the rest. *That* is why sort and sortBy need to exist. > > > I'm not convinced by this, but in any case just because something is > inlineable, does not mean the compiler has to inline it. >>> >>> The other part, how to sort a composite object by different properties >>> seems best handled by wrapping the object in a view. In other words >>> PeopleByAge is a different type than PeopleByHeight and these would override >>> 'less than' on the object. In fact People should not be sortable as it is >>> ambiguous. >> >> Aside from the fact that this is a solution only a mathematician could >> love, and it will compile to horrible code, it's fine. I've seen algorithms >> where the same collection is first sorted one way and then another way **in >> place**. The approach you are advocating here may be relying on a tacit >> assumption of [pure] functional programming. > > > Its a solution I love, and I am not a mathematician. I also don't think the > code will be any more horrible than sortBy, as the type classes would get > inlined, resulting in the comparison function being passed exactly like > sortBy.
No, it's extremely different from sortBy. In the sortBy case, the information about how to compare is stored *once*. As far as I can tell, your proposal requires O(n) extra memory and either duplicates the information for comparison n times or precomputes all the keys and stores them explicitly. Geoffrey _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
