Sorry, doing syntax conversions in my head, ValueType should be an associated type, not a type class, so:
sort :: (ForwardIterator i, PartialOrder (ValueType i)) => i -> i Collections can of course provide reverse iterators as well as forward ones. I would see ListReverseIterator as a different type from ListIterator, again different from ArrayIterator. Keean. On 3 Jan 2015 04:45, "Keean Schupke" <[email protected]> wrote: > 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
