Perhaps I should add a little explanation. f :: Show a => a -> IO () f x = putStrLn (show x)
Although we don't know the type of a when we define 'f' (all we know is that there must be an instance of show for 'a' which gives us the type information for checking the definition if f), at some point we use 'f': g :: IO () g = f "test" When we do this we polyinstantiate the type of f, and unify 'a' in the instance of f's polymorphic type with String. This enables us to statically (at compile time) specialise 'f' for String. With an implicit argument, 'g' might be called from somewhere that has a different instance of Show String in scope, meaning we cannot statically specialise. I think modules and dependent types have the same problem, but I would be happy to be proved wrong, as dependent types seem to make a lot of things simpler. Keean. On 3 May 2015 17:00, "Keean Schupke" <ke...@fry-it.com> wrote: > > On 3 May 2015 16:16, "Matt Oliveri" <atma...@gmail.com> 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 bitc-dev@coyotos.org http://www.coyotos.org/mailman/listinfo/bitc-dev
