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] Cheers Keean. On Fri, Jan 2, 2015 at 3:51 PM, Keean Schupke <[email protected]> wrote: > Well the other problems are more of a taste issue. With one instance per > type we can leave the type system to infer the correct instance. this means > that generic functions can have type signatures that take a single type > parameter (or a minimal set of type parameters). > > When we want a function that does some maths, uses some collections etc, > then we might have: > > test :: Numeric s, Numeric t, Map t s, Map s t => s -> t > > We can then use test on something like: > > test 7 8.3 > > and the type-class dependencies are satisfied (or not) automatically. > > However if we use implicit parameters (or type parameters as in dependent > types): > > test :: (Numeric s) -> (Numeric t) -> (Map t s) -> (Map s t) -> s -> t That's just syntactic sugar. Unless every single type satisfies the constrain, *someone* has to add the type class argument at some point. It's nicer if it's the compiler, but there's no reason the compiler can't do it if we don't assume coherence. If you're saying you'd prefer to write down the type signature without associated type constraints, that also maps over perfectly well to a world without coherence: we just give the compiler the freedom to add type class constraints not specified by the user. Geoffrey > Now when we call we have to pass the right dictionaries: > > (test numeric_int numeric_float map_float_int map_int_float int float) > > Now it is up to the caller to ensure the dictionaries passed have the > correct relationships to each other, so that the dictionary for the first > argument related to the type of the second argument of the type associated > with the third dictionary argument. > > I find this second way of structuring things gets really complicated very > quickly, and has caused me problems in languages that require this sort of > thing (ML, and Ada for example). All of that seems like syntactic sugar. We can certainly _______________________________________________ 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
