You will have multiple implementations of sort for the different algorithms anyway, you want different collections to use different sort algorithms based on the supported iterator concepts (forward_iterator, bidirectional_iterator, indexed_iterator, random_iterator). What I would want is something like:
sort :: (ForwardIterator i, ValueType i x, PartialOrder x) => i -> i : : : sort :: (RandomIterator i, ValueType i x, PartialOrder x) => i -> i A partial order only defines less than so there is no ambiguity. The correct sort is chosen by overloading the definition on the type - classes. So no multiple definitions and because overloading is on type-class, multiple definitions for the same type do not make sense. x is either a partial-order or it is not. For a sortable object like a database table, I would expect the table object to be wrapped in a dynamic view that captures the user input and defines the comparator for the view appropriately. Keean. On 3 Jan 2015 00:52, "Geoffrey Irving" <[email protected]> wrote: > On Fri, Jan 2, 2015 at 4:28 PM, Keean Schupke <[email protected]> wrote: > > Is it just sugar? You can definitely allow overlapping instances where > one > > is a better fit by changing the instance resolution rules. I have no > problem > > with this kind of overlap. > > > > You can allow backtracking in instance resolution, so that dependencies > on > > other type classes play a part in instance resolution, and I have no > problem > > with that either. In fact this is what I am doing in my own project. > > > > The only kind of overlap I have a problem with is where there are to > > instances for a single type, which are indistinguishable to the type > system, > > and hence require passing an instance value as a parameter. I think that > > this reflects a mistake in program structure. > > > > The often quoted example of different sort orders is better expressed as > two > > separate functions for the order, so that there is only a single > instance of > > Ord for the types involved > > > > sort_ascending :: Ord x => [x] -> [x] > > sort_descending :: Ord x => [x] -> [x] > > Presumably you're imagining a third sortBy function that types an > explicit comparison function, in terms of which sort_ascending and > _descending can be implemented. Otherwise you have to implement the > sorting algorithm three times. Even if sortBy is the only nontrivial > function, we still have three functions instead of one. My view would > be that three functions instead of one is a mistake in program > structure, which is probably just a philosophical difference. In any > case, if we've moved from soundness and decidability questions to > philosophy, success! :) > > 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
