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
