On Wed, Jan 7, 2015 at 3:54 PM, Keean Schupke <[email protected]> wrote: > On the soundness issue, I think I now understand it a bit more. I don't > think there is a problem with type-families, nor with the way Haskell > handles associated types (which is as a type function of the type-class > parameters). > > It comes down to this, the associated types of instances with the same type > parameters must be the same. So the instances must be coherent as far as the > type system is concerned, but can have different values (function > definitions with the same parametric type signatures)
What are the differences between type families and associated types in the context of bitc? That is, if only associated types must be coherent, can we do without them? > However I think it is a good idea to separate compile time from runtime. > Type classes can be entirely inlined at compile time except two cases I am > aware of, polymorphic recursion, and existential types. Polymorphic > recursion is somewhat problematic, so leaving it to one side, I would like > to treat all type-classes like C++ templates, and existentials as virtual > functions, where you define a base class for the type-class, and then > override for each instance. This means runtime polymorphism is introduced > only where intended by the programmer, all types can be unboxed as all > polymorphism is static apart from that introduced by an existential, which > is equivalent to an abstract base class with one layer of subclasses. We can't separate compile time and runtime in this way if we want to avoid sortBy. The comparison function can easily depend on runtime data, the canonical example being sorting a list of values by a key stored in a separate map. Geoffrey _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
