On 3 May 2015 03:19, "Matt Oliveri" <atma...@gmail.com> wrote: > 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.)
I don't think that is good enough. Haskell could be as fast as C++ if the compiler was good enough at optimising. I don't think it will ever happen. Modules have the same problem due to instance arguments and containing state. Instance arguments mess up static resolution too. As do dependent types, by making everything uniform to the programmer they rely on the mythical sufficiently clever, that has been promised for decades, and although there have been improvements, is not anywhere near available. So the phase difference needs to be explicit, so the programmer knows when they are using a costly abstraction, and can decide if they need the performance or not. Type classes work because they are stateless interfaces, and the one to use is entirely determined by the type (which is known at compile time) and is independent of any runtime dynamic scope (the path taken to reach a function has no effect on instance selection). So if we can restrict type classes to static resolution, and you pass a value explicitly when you need runtime polymorphism, you get visibility of the performance cost. As for your question type classes can be statically resolved for all cases, unless existentials are used to introduce runtime polymorphism (polymorphic recursion is tricky but solvable with some loop unrolling for each type). Keean.
_______________________________________________ bitc-dev mailing list bitc-dev@coyotos.org http://www.coyotos.org/mailman/listinfo/bitc-dev
