The 'mixin' keyword is reserved, so yes, it is on our mind. There are two distinct activities here:

- Implementing functions and objects: i.e. sharing implementation fragments when building functions and objects that implement existing types (e.g. building a value of type seq<int> that returns a particular sequence)

- Implementing types: i.e. sharing implementation fragments when implementing new types that have "broad" signatures (e.g. types that need to implement IDisposable, IEnumerable, ICollection, IList, IFoo, IBar etc. etc.)

Implementing functions and objects works extremely well in F#. Implementing broad-signature types is done less frequently than in the languages you mentioned above, but I agree could be more satisfactory.

Basically, in F# you end up writing fewer explicit types/classes than you would in the languages mentioned above. If you take a look through the IEnumerable/Seq module implementation you will see what I mean: in the whole implementation the myriad of IEnumerator and IEnumerable objects you won't see a single type/class definition. (There are, of course, many object expressions. In many of these cases the OO programmer may have been reaching for implementation inheritance, mixins, etc. etc. )

When it comes to implementing broad-signature types I agree the situation is different for F#. For example, if you implement the IDisposable or ICollection interface on a type (a much more infrequent activity than in many other languages), then you will indeed find yourself repeating code fragments. If a type supports N interfaces with M methods each you still need N*M methods in the definition of the type, unless you resort to implementation inheritance (a poor form of mixin). Ultimately the underlying implementation fragments of these can still often be shared, but the veil can't be.

Now, this isn't a wholly bad state of affairs: sometimes looking at mixin-based code can be awful. To use an analogy, think about looking at a complex machine like a car. If the car is described using mixins, then reading the mixin code is like reading the foreign-language construction manual for the car: if you're lucky you'll just manage to understand how it was put together, but it's hard to see the overall "thing". And who cares how it was put together as long as it drives well and is safe? The user wants to see the N*M final result: to see everything the car can do and to understand how to drive it. So mixins are good for the library implementer, but they aren't necessarily so great for the user.

That said, a well designed library of mixin fragments can save a lot of time for new library authors. So I agree mixins for fragments of type definitions are on the cards to address these kinds of issue. But they are less important for F# than for OO languages.

regards,

don