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. sorting both ways in place is fine, you would sort each view of the collection. > To do this for runtime data just requires an existential wrapper, which of >> course makes explicit the need for runtime polymorphism. >> > Perhaps. But the runtime cost of that existential is intolerable in many > of the programs we wish to write. > The runtime cost of the existential should be the same as a virtual function, which is a necessary cost for runtime polymorphism. The cost should be no more. Keean.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
