Allow all declarations to be mutually referential and the compiler takes files in any order
With F# becoming more and more multi-editor and cross-platform, it is becoming increasingly difficult to teach all build/edit tools about F#'s file order. The F# community are currently struggling to "update" each new build/edit tool to understand that F# actually needs a file order.
Part of the problem is that there is no standard textual way to specify this file order except as command line arguments, and these are not stored in an editable form. There is no standard way to specify the F# file order. We need an (optional) solution to this problem that is closer to home and doesn't involve modifying build/edit tools.
This proposal is one of three alternatives to deal with this problem in the F# language/compiler itself.
The specific proposal covered by this UV entry is to just change F# to use no file order at all, allowing all declarations in an assembly to be mutually referential with other declarations.
Related alternative: Keep a file order, but infer it from #load/#require declarations. This is covered by https://fslang.uservoice.com/forums/245727-f-language/suggestions/6323146-syntactically-describe-dependencies-between-files
Related alternative: Keep a file order, but optionally have it specified by a fileorder.fsx or fileorder.txt or fileorder.json: https://fslang.uservoice.com/forums/245727-f-language/suggestions/13394442-optionally-specify-file-order-by-a-fileorder-fsx
Yaar Hever commented
I'm also against it. Letting the compiler figure out the order of dependency only postpones the problem and eventually leads to spaghetti code and cyclic dependencies.
I find that this constraint + the fact that mutually recursive functions and types require the "let/type ... and ..." syntax actually help in reasoning about the structure of the code.
See also this article (and the references at its end): http://fsharpforfunandprofit.com/posts/recipe-part3/
Jack Fox commented
Unless this is a win in some area I do not understand (like tooling) I too would down-vote this idea.
Radek Micek commented
@DK Unfortunately this is not so simple. Different file orders may result in different behaviours (eg. when a type is in referenced assembly and a type with the same name is also in current assembly).
I think this is a brilliant idea! And the best part is -- it doesn't cancel out the enforced file order.
Having a tool deduce file order (and for example, update file order in solution explorer automatically) will let us keep the best of both worlds.
Onorio Catenacci commented
Can someone vote against an idea? This is a bad idea.
F#'s enforced compilation order is a _good_thing_.
Colin Bull commented
Personally, having the enforced order of the files is a big win for me. It allows me to pick up a project and instantly know where to start figuring out how things work. This is especially useful for libraries which do not have such an obvious entry point as is available in console apps; also since the compiler enforces it is the same across all projects, no matter the developer. I realise that this can be somewhat of a hurdle for beginners, but for maintainability of a code base it is invaluable.
Mark Seemann commented
Like Daniel Robinson, I think that since the order matters, being able to view that order at a glance is valuable.
If that feature is removed, I suspect we'll see files named 010Foo.fs, 050Bar.fs, etc. That's not a place I'd like to go.
Daniel Robinson commented
If we go the #include/#load route, I hope VS will still require dependency order. My 2 cents.
Daniel Robinson commented
I'm confused. Isn't being able to view file dependencies at a glance, based on file order, a good thing for the same reason types are required to be defined in order?