SortBy should not exist. By defining sort on a partial order, there is only one sort direction.
The other part, how to sort a composite object by different properties seems best handled by wrapping the object in a view. In other words PeopleByAge is a different type than PeopleByHeight and these would override 'less than' on the object. In fact People should not be sortable as it is ambiguous. To do this for runtime data just requires an existential wrapper, which of course makes explicit the need for runtime polymorphism. Keean On 8 Jan 2015 00:02, "Geoffrey Irving" <[email protected]> wrote: > 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 >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
