I suggest we ...

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

39 votes
Vote
Sign in
(thinking…)
Sign in with: facebook google
Signed in as (Sign out)
You have left! (?) (thinking…)
Kevin Ransom shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

29 comments

Sign in
(thinking…)
Sign in with: facebook google
Signed in as (Sign out)
Submitting...
  • Yaar Hever commented  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    Unless this is a win in some area I do not understand (like tooling) I too would down-vote this idea.

  • Radek Micek commented  ·   ·  Flag as inappropriate

    @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).

  • DK commented  ·   ·  Flag as inappropriate

    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.

  • Colin Bull commented  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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?

2 Next →

F# Language

Feedback and Knowledge Base