On Tue, Jul 16, 2013 at 9:55 PM, Bennie Kloosteman <[email protected]>wrote:
> Why cant i have a large standard lib ...with traits and use a lot of c > style modules in my code "modules" ? Together they form a large app... > Because trait implementations either (a) do not respect crate boundaries [according to the language reference] or (b) mean that generic functions whose instantiations make use of traits cannot access the trait implementations for types defined in some other crate. In the first case, there is a coherence problem, an induced whole-crate compilation requirement, and a failure of link safety. In the second case, traits are effectively unable to cross crate boundaries, which is what the manual seems to imply. The impact of the second alternative would be pretty bad. It means that a sort implementation in one crate that relies on an implementation of an Ord trait cannot make use of an Ord implementation supplied in another crate. That is: unless traits are first class types, which is a potentially interesting way to resolve this puzzle. The main problem that concerns me about trait implementations and type class implementations is the link safety problem. If a reasonable bound can be set on the link safety problem, then I *think* things can be made to work. Oh. The absence of a single implementation at any given type also gives rise to some pretty bad dictionary merge problems... "App architecture is unquestionably important. No argument. Nonetheless, > mistakes in the language design - in this case the absence of lexical > scoping for impls (aka type class instances) - can destroy any hope of > success for the best imaginable architecture." > > I dont think it stopped Haskell ... > Umm. Bennie? Name *one* large system that has been implemented in Haskell. Haskell hasn't been stopped because it hasn't attempted the challenge. Jonathan
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
