I think Jason has a point here. The lack of module merging (see exportall, reexport,...) makes include more necessary than it might be. Further we really need #4600.
To be honest: When going through packages I have found myself using the "includes" to understand the package structure. Cheers Tobi Am Montag, 29. Dezember 2014 18:21:35 UTC+1 schrieb Jason Merrill: > > > > On Sunday, December 28, 2014 9:24:38 PM UTC-5, Mike Innes wrote: >> >> I can only speculate about the reason that people still use include, even >>> though Julia has nice modules. >> >> >> Well, I for one think that >> >> 1) Modules containing a large number of functions are OK (and this is >> very common in more functional languages) >> 2) If you're going to have (1), you want to split that module across >> multiple files. >> >> Languages which embrace (1) but conflate modules and files tend to end up >> looking like this >> <https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj>. >> Personally, I prefer the Base's organisation, and would be happy to never >> see a 7,000 line Julia file. >> > > I'm in complete agreement with both of your points here--I'm just saying > that `include` is a problematic way of achieving these goals. > > To rephrase it again, the main thing that I don't like about `include` is > that when you are reading a file that ends up being included somewhere > else, in general you have to know what context it is going to be included > in to know how it will work. That information is not present in the file > itself. This essentially forces you to understand new packages in a top > down way (because you must first find all of the `include` statements), > instead of having the option of reading them bottom up or top down. > > The main useful property of a module over a naked `include` is that when > you are reading the module, all of the relevant information about scope is > present in the file itself, instead of existing in a different file at the > `include` site. > > I haven't done a careful analysis, but I hypothesize that if you look at > how `include` is used in high quality packages, you will generally find > that included files don't actually use the scope of the environment they > are included into, so from that standpoint, they could usually be modules > instead. But I bet you'll also find a few instances where they do use that > scope, and you'll never know when without a close reading. > > This is why I'm suggesting that maybe what Julia needs is better > mechanisms for composing small modules into larger modules. The goal would > be to achieve your points (1) and (2) without having lots of files that run > in a mystery scope. >
