On Sat, May 2, 2015 at 3:11 AM, Keean Schupke <ke...@fry-it.com> wrote: > Going back to the set problem, one thing we know is that all sets passes to > fast-union must have the same order, so: > > - we can assume the order inside the definition of fast-union. > > - if we can determine the order from the type then we can specialise fast > union, and we don't need to pass the order as it is implied from the type > (type class case) > > - if the order is passed in as a value we cannot specialise it, here order > is a record containing the cmp function identical to the dictionary that > would be referenced at compile time in the type class case.
Whether you can specialize based on an argument doesn't depend on whether that argument is a value, but whether the argument is known before runtime. I've gotten the impression that typeclass instances are not necessarily known before runtime either, in Haskell. Can anyone confirm? > This seems to fit with the use of implicits. The problem comes in deciding > whether to use the passed instance or the global one. This only gets worse > in nested functions, if you pass an instance of Ord do we expect all sub > functions to respect it if we do not explicitly forward it. If we do, then > we have no choice but to dynamically resolve all type classes as you never > know which ones are in scope in the callers runtime environment (and I think > dependent types have this problem too?). I don't know how your system decides what to pass as an implicit argument, but if the thing it decides is any better than just a variable, you might be able to usefully specialize. Also, specializing one function gives you more information about how to specialize the functions it calls. How to specialize based on an argument need not have anything to do with whether that argument was implicit, or whether it's a value. Specializing based on a value is partial evaluation, I figure. So specializing based on typeclass instances is essentially already partial evaluation, since instances are essentially records, as you know. > So I seem to have changed my position from one of supporting implicits, to > one of rejecting them. But this means having two separate implementations of > everything, one using type classes and one explicitly passed functions, > which I don't like either. I think you're confused about when functions can be specialized effectively, and this may be messing up your decisions about language features. I don't think specialization is much different whether you use modules, typeclasses, instance arguments, or dependent types. In all cases, runtime behavior is effectively influenced by the type, and this can be implemented more efficiently if you know enough about the type to know what the (runtime) behavior should be at compile time. (With dependent types, the behavior is not literally influenced by the type, but by an argument which is implicitly chosen based on the type. I guess this is true of typeclasses and instance arguments too.) _______________________________________________ bitc-dev mailing list bitc-dev@coyotos.org http://www.coyotos.org/mailman/listinfo/bitc-dev
