Should I leave non-function values in modules or bring them to the main program file? - module

Question

This is a question about how I should organize my F# code. I hope it is not in violation of SO rules.
I have dozens of source files (names terminating in .fs) in my project. Each file contains a module. In some of these files/modules I define only functions. In others I define functions and other values (not functions).
The last file in the Solution Explorer (Visual Studio) is Program.fs which actually contains very little code. Most calculations have been done "above" it.
I am considering moving the non-function values declared in the other modules to Program.fs. These are the advantages and disadvantages I see from this change:
Advantages:
1) A better view of program flow.
2) Easier to select all code above a certain line and send it for execution in FSI.
3) Slightly easier to search for those values in the editor.
4) Possibly easier to debug by putting breakpoints on the lines where values are declared.
Disadvantages:
1) Program.fs could become large and unwieldy.
2) Loss of modularity.
3) After implementing the changes, if the calculation of value y in module B depends on value x in module A "above" it then I can no longer have y as a value, it must be declared as a function of x. Similarly if a function declaration in module B depends on a value in module A I must add a parameter to the function definition.
Below are two examples of the same small program created under the two alternative methods. Which of the two is better in general?
// ///////////////// Values in modules \\\\\\\\\\\\\\\\\\\\
// File A.fs
module A
let i = 1
let add x y : float = x + y
// File B.fs
module B
let sqr z = z * z + float i
let x = sqr 99.9
// File Program.fs
open A
open B
let y =
add (float i) x
|> sqr
printfn "%f" y
[<EntryPoint>]
let main argv =
printfn "%A" argv
0 // return an integer exit code
// This is the calculated value for y: 99640524.640100
// ///////////////// Values in Program.fs \\\\\\\\\\\\\\\\\\\\
// File A.fs
module A
let add x y : float = x + y
// File B.fs
module B
open A
let sqr i z = z * z + float i // notice the additional parameter
//File Program.fs
open A
open B
let i = 1
let x = sqr i 99.9
let y =
add (float i) x
|> sqr i
printfn "%f" y
[<EntryPoint>]
let main argv =
printfn "%A" argv
0 // return an integer exit code
// This is the calculated value for y: 99640524.640100

Answer 1

As you presented it, the second version (with values moved to Main) is better imho. You pretty much nailed it with the #1 advantage and it's a really big one. As for the disadvantages you listed:
Large main: Yeah, depends on how much stuff we're talking, worst case you could keep the values in yet another module used just by main and just for values. Think "Config module"
Loss of modularity: I can't see
why. If anything it increases the modularity? Your main does not
depend on module X having some value, it provides it. You can then swap the module with another satisfying the same interface and not care about ripple effect it could have on other modules. If you have a large hierarchy of modules you could look into representing it in your main as per dependency inversion principle - it would take some work but the good news is that in functional languages you don't need IoC containers, partial application does the job
If module B depends on a value existing in module A it isn't very modular to begin with, is it? It's a good thing that you will have to change it into a function - it will explicitly say what is now implicit
Note that I'm writing this from my mostly OOP experience, so in functional programming some of it may be not applicable