On Thu, Jul 18, 2013 at 7:28 PM, William ML Leslie < [email protected]> wrote:
> On 19 July 2013 02:54, Jonathan S. Shapiro <[email protected]> wrote: > > > For a language to work at scale, I feel that both problems need a > reasonable > > resolution. Rust may in fact have one, but I'm unable to tell from the > > manual and the wiki entries that I've seen so far. > > Someone will probably retort that most "languages [that work] at > scale" don't really have the functionality you're talking about. That's true. But that's not a reason to dismiss the concern. That's the problem we're trying to solve! These aren't just features "at the margin". In languages that have type classes or traits, these features are utterly essential to use of the language. As one example, they provide the source of genericity. This isn't a feature you can avoid. In particular, you can't just say "well, restrict your APIs at crate/assembly boundaries so that they don't use interfaces and you are good to go". If we're going to bring these features into use in large systems, they have to be link-safe. So, it is important to note that we're not attempting to solve the > expression problem here (am I wrong?). What we actually want to do is > be able to describe new implementations of existing traits, and then > to be able to call library code that expects some object that > implements that trait. That is *not* the problem. If we were restricting the language such that objects implement their traits as part of the object implementation we would be done and there would be no resolution problem. That approach would obey lexical scoping. The problem in Rust is that we want to call library code that expects some object *for which a unique implementation can be resolved by non-lexical means while preserving link safety*. > We can also conflate the idea that that the implementation of the > functions are inline-able into library code, but that's a separate > concern. That's a separate concern, but not one that we can ignore when instances are used for ground operations. The design of the instance/implementation mechanism must preserve the possibility of inlining at ground types - at least when the interface/implementation is not used as a first-class object. Jonathan
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
