2 ms·

> [...] It's not typically considered a benefit[...] ...see sibling comment, where the commenter does seem to imply they rather like it.

by gyulai 3y ago

electroly 3y ago
I stand by my statement. Sibling comment is not typical. There's a reason that file order is rare among programming languages. Languages never decide to mandate this out of the blue when their language design doesn't otherwise require file order; it's something you only mandate if you can't implement orderless files. You get a bunch of nice properties when they're not strictly ordered, like compiling files in parallel, rebuilding an earlier file without having to rebuild a later file, etc. In F#, compilation is forced to start at the first modified file and proceed linearly to the end of the project. OP's technique, notably, avoids these problems by numbering the files but not actually mandating at the compiler/language level that they be ordered. Here they are acting as a hint to the programmer but the files are still, as far as the language is concerned, orderless. That would seem to be a nice compromise if you like the idea of an ordered codebase. More of a literate programming technique.
- gyulai 3y ago
  Is that just because F# is a typed language? My personal experience has been that it's a pain to implement this as soon as you have strong typing and try to avoid "unsafe" casts. For example, in modern Java, if you have some kind of a Container<T> over elements of type T, and a matching ContainerIterator<T>, you will want some way in each of the type declarations to refer to the other type declaration, so you need cyclical imports. If you look at it through the lens of a dynamically-typed language like Python 3.4 or Lua, the problem just disappears. This is the case to a lesser extent even for Java before it had generics, and collections were just collections of Object, and you used "unsafe" casts all the time. I am finding this practice not the slightest bit limiting in Lua, nor do I get the feeling that the readability of my code suffers in any way at all. (Rather the contrary, as I've pointed out before).
  - electroly 3y ago
    I wouldn't blame the static type system; this is more of a language design decision of its own. IMO, F# does it this way because ML did it this way. I think it's more of a cultural norm than a technical decision. There is a certain theoretical purity to requiring ordered declarations across a whole project. It's valuable to compare F# against C++ here. F# and C++ both require ordered declarations within a file (while C# and Java do not), but F# requires the files themselves to be ordered, too, while C++ does not. Both are statically typed languages. C++ avoids requiring a file-level order by defining file-level compilation units and a system for importing and exporting symbols between compilation units to allow each file to be processed separately with the imports/exports resolved during a final linking phase. There's complexity involved in accomplishing this. F# has not done it; an F# project is the same as concatenating all of the source files together, and thus declarations must be ordered across files just like they are within a file.

> [...] It's not typically considered a benefit[...] ...see sibling comment, where the commenter does seem to imply they rather like it.

by gyulai 3y ago

> [...] It's not typically considered a benefit[...] ...see sibling comment, where the commenter does seem to imply they rather like it.

electroly 3y ago

I stand by my statement. Sibling comment is not typical. There's a reason that file order is rare among programming languages. Languages never decide to mandate this out of the blue when their language design doesn't otherwise require file order; it's something you only mandate if you can't implement orderless files. You get a bunch of nice properties when they're not strictly ordered, like compiling files in parallel, rebuilding an earlier file without having to rebuild a later file, etc. In F#, compilation is forced to start at the first modified file and proceed linearly to the end of the project. OP's technique, notably, avoids these problems by numbering the files but not actually mandating at the compiler/language level that they be ordered. Here they are acting as a hint to the programmer but the files are still, as far as the language is concerned, orderless. That would seem to be a nice compromise if you like the idea of an ordered codebase. More of a literate programming technique.

gyulai 3y ago
Is that just because F# is a typed language? My personal experience has been that it's a pain to implement this as soon as you have strong typing and try to avoid "unsafe" casts. For example, in modern Java, if you have some kind of a Container<T> over elements of type T, and a matching ContainerIterator<T>, you will want some way in each of the type declarations to refer to the other type declaration, so you need cyclical imports. If you look at it through the lens of a dynamically-typed language like Python 3.4 or Lua, the problem just disappears. This is the case to a lesser extent even for Java before it had generics, and collections were just collections of Object, and you used "unsafe" casts all the time. I am finding this practice not the slightest bit limiting in Lua, nor do I get the feeling that the readability of my code suffers in any way at all. (Rather the contrary, as I've pointed out before).
- electroly 3y ago
  I wouldn't blame the static type system; this is more of a language design decision of its own. IMO, F# does it this way because ML did it this way. I think it's more of a cultural norm than a technical decision. There is a certain theoretical purity to requiring ordered declarations across a whole project. It's valuable to compare F# against C++ here. F# and C++ both require ordered declarations within a file (while C# and Java do not), but F# requires the files themselves to be ordered, too, while C++ does not. Both are statically typed languages. C++ avoids requiring a file-level order by defining file-level compilation units and a system for importing and exporting symbols between compilation units to allow each file to be processed separately with the imports/exports resolved during a final linking phase. There's complexity involved in accomplishing this. F# has not done it; an F# project is the same as concatenating all of the source files together, and thus declarations must be ordered across files just like they are within a file.