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. 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. 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. > 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. > 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. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
