Good question. The answer is reliability. The linearity that has been observed here allows this family of languages to enforce a well-defined order of evaluation on the entire program and that is absolutely essential for value-based (rather than class based) languages like F#. The ad-hoc evaluation order that Oliver is advocating is even completely prohibited in many languages from the ML family. The F# compiler will actually let you do this but it emits a warning because this is a dangerous practice.

In fact, if Oliver’s last code snippet did compile it would be an infinite loop, with the constructors invoking each other indefinitely. I suspect the desired functionality was to construct two mutually-dependent objects simultaneously but that requires the manipulation of partially constructed objects. If either construction sequence contains side-effects (as is the case here because constructing ClassA invokes DoSomethingInB that prints to the console) then the evaluation order of these statements is undefined and the program becomes non-deterministic.

Having said that, my proposed idiomatic-OCaml solution does not work in F# as Oliver noted. The reason is that OCaml has structurally-typed objects so it can infer classes whereas F# requires class types to be explicitly declared beforehand (just like a header file).

Finally, regarding the Solution Explorer in Visual Studio for F#, I agree completely that the current implementation is dreadful. The F# team are completely rewriting the VS mode and, hopefully, the new version will make it into the CTP this summer. My personal opinion is that the VS mode is by far the weakest point of the current F# distro.

I agree that the human can work around it. However, I would question why I want a feature in the language that requires a human to rewrite an otherwise correct type hierarchy when introducing a cycle in the type dependency. This makes it much more difficult to predict the cost of making a change–the cost could vary by more than an order of magnitude depending on whether the change introduces a cycle or not.

What does the F# user gain from the ordering requirement?

Thanks for your comment. I have to admit though that I don’t have the first clue how your suggestion is supposed to work in reality… I wrote this little piece of code to model what you said:

type ClassA<'b when 'b : (new : unit -> 'b)>() =
    let foo = new 'b()
    let test() =
        foo.DoSomethingInB()
	
type ClassB<'a when 'a : (new : unit -> 'a)>() =
    let foo = new 'a()
    member x.DoSomethingInB() = printfn "Doing something"
	
let classA = new ClassA<ClassB>();

Now, there are two major problems with it:

1. The final line doesn’t compile, because ClassB on its own isn’t accepted - after all it’s ClassB<’a>. So this results in an endless ClassA<ClassB<ClassA<ClassB<…. chain, which I have no idea how to resolve.
2. The line foo.DoSomethingInB() doesn’t compile, because it makes assumptions about ‘b that the compiler can’t check. I would have to use a type annotation to make the compiler understand which type(s) I’m expecting, and that in turn would reintroduce the dependency I’m trying to get rid of. I don’t see how there’s a way around this if I’m ever going to do anything meaningful with the classes I depend on.

Theoretically, your idea is interesting. While we don’t support these generic class structures in our library right now, it would be possible to extend without introducing a dependency to F# into our code. But I just don’t see how this should work, since especially (2) above seems to be a general problem with the approach. If you know what the solution is, perhaps you could remodel my little sample above so that it works?

Thanks
Oliver

You are right - renaming the files actually does change the order in the project! Unbelievable, that’s ridiculous. You know, if the order was entirely unimportant, then this wouldn’t matter. But seeing how the order is in fact extremely important for all the reasons I’ve listed above, this is a major issue.

Oliver

Consider the mutually recursive type definition:

type stuff = Stuff of things
and things = Things of stuff

Rewrite it like this:

type ‘a stuff = Stuff of ‘a

type ‘a things = Things of ‘a

This idiomatic functional approach is sometimes called "untying the recursive knot" and it allows you to split any definitions (type or value) across any boundaries you like (e.g. source files or even DLLs).

As to the interrelated class problem, I am surprised to read that it is such an issue. We have been using F# for over a year now at my company and have only run into what you describe in a few GUI related instances. I would recommend taking another look at generics to help you with the large hierarchy. In a language like F#, polymorphism like .NET’s generics often proves superior to runtime polymorphism with class hierarchies.