I'm probably being slow, but I don't see that. With sortBy you pass the comparison function explicitly. With a 'view' the comparison function is passed implicitly (by they type). That is the only difference. A view is simply type that overrides the comparator.
Where is the extra memory etc coming from? Keean. On 8 January 2015 at 01:11, Geoffrey Irving <[email protected]> wrote: > 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 >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
