On Sun, May 3, 2015 at 3:13 AM, Keean Schupke <[email protected]> wrote: > On 3 May 2015 03:19, "Matt Oliveri" <[email protected]> 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.
I'm not trying to say it should be good enough for you. I'm saying that from the perspective of optimizability, all the options we've been discussing are no more or less good than one another. > Haskell could be as fast as C++ if the > compiler was good enough at optimising. > I don't think it will ever happen. Me neither. What's your point? We started by discussing the correctness and convenience benefits of typeclasses vs. instance arguments. There's no difference in performance. > Modules have the same problem due to instance arguments and containing > state. Which language is this with both modules and instance arguments? MLs don't have instance arguments, I thought. > Instance arguments mess up static resolution too. As do dependent > types, Yeah, all of the things we've discussed have the same problem that you can't always specialize. > 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. No, the language designers are well aware that you can't always specialize. There is no scandal of the missing optimizer. It's just that most language designers apparently don't think static resolution is as important as you do. > 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. Yeah I know you want this. It's not a bad idea. But it seems totally orthogonal to typeclasses vs. instance arguments vs. dependent types. > 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). But the type _isn't_ always known at compile time. That's what I've been trying to tell you. Whether you know something at compile time is unrelated to whether it's type-level or not. If they were the same, you'd be absolutely right that dependent type systems break phase separation and are bad news. But you're wrong. Stages/phases and strata are unrelated phenomena. Dependent type systems get rid of strata, and this need not have any effect on staging. > 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. I don't think implicit instance vs. explicit value is a good way for the programmer to control whether to allow runtime polymorphism. Try staging annotations. > 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). Which question was that? Even if you're right that type classes can be statically resolved in the absence of existential types, I think staging annotations would be a better way for the programmer to force specialization. Not relying on some brittle property of a type system that's been crippled in just the right way. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
