Sorry, realised I only answered the second part. I also want to point out that there is more than one way to do everything, and certainly dependent types with aggressive partial-evaluation would work, and possibly be more expressive than the option I am presenting. The advantage of my proposal is it makes explicit to the programmer the cost of runtime polymorphism, IE it only occurs where the programmer permits it. With dependent types static polymorphism (and the improved performance) can only come where optimiser can prove it does not need to be dynamic. With a perfect compiler these would be the same, but with the former you have visibility of the cost in the source code, with the latter a much more complex compiler.
To come back to can you do without associated types / type-families, I know I would need one or the otherfor knowing the ValueType of an Iterator that is passed in as an argument. The advantage of type-families is that you can keep the associated types coherent, even if the type-classes are not. Keean. On 8 January 2015 at 00:08, Keean Schupke <[email protected]> wrote: > 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
