On 3 May 2015 16:16, "Matt Oliveri" <[email protected]> wrote: > 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.
Type classes with global coherence can be resolved statically, the other methods cannot. > > 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. The difference in performance between c++ where templates (which can be modelled in a type safe way as type classes) and languages that have to use dynamic dispatch is not small. > Which language is this with both modules and instance arguments? MLs > don't have instance arguments, I thought. Sorry that should have said associated types. > 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. C++ does not take that approach. Systems programming languages need to make performance issues visible to the programmer. > 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 with global coherence can be statically resolved (when not combined with existentials). > But the type _isn't_ always known at compile time. If there is no existential encapsulation the types are 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. I disagree, you need existential types to enable runtime polymorphism, otherwise type safety requires you know all types at compile time. Otherwise type checking would not work. > 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. Well we might have to agree to disagree, although you would save me a lot of wasted time if you could prove or convince me they are unrelated. > Dependent type systems get rid of > strata, and this need not have any effect on staging. You need to introduce staging with dependent types, because they remove the relationship between phase and strata. > 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. Why introduce a new mechanism and additional complexity when you don't need to? Also why is it not a good mechanism, you pass a value because values can change at runtime. You rely on implicit global instance resolution because it can only ever be one thing. > 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. What you call a brittle property is something that seems fundamental and important to me. Keean.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
