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
