> – but, Julia largely obviates the name clash problem via multiple dispatch, meaning you can have large namespaces very safely
Yes, absolutely, this is a very important point when comparing namespacing strategies with other languages. I would go further and claim that with multiple disptach, you WANT to have large namespaces. The power of multiple dispatch comes about when you have many functions with the same name. The fact that (+) has 117 methods is a feature, not a problem. Modules and multiple dispatch have some tension here. This is the reason we have the slight complications of import/using etc. So when comparing module systems with single dispatch languages, we need to consider the special needs of multiple dispatch in this area. Slightly more generally, I think we are all figuring out how to architect large systems using multiple dispatch. The definitive book on that subject has not been written yet. It certainly will not look like a Java application. Regards - Avik On Monday, 29 December 2014 02:24:38 UTC, 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. > > Now, arguably Clojure could benefit from going with (1) a little less than > it does, because of the potential for name clashes – but, Julia largely > obviates the name clash problem via multiple dispatch, meaning you can have > large namespaces very safely. On top of that, having lots of small > submodules destroys a huge convenience factor, since you suddenly have to > think about lots of internal sub-APIs. But maybe there's a compelling > argument for small modules that I've missed. > > Another key point here is interactivity. If I reload a file in Julia, I > *actually > want* and fully expect that include statements and the relevant files > will be reloaded, whereas I don't want to reload every package dependency. > It's great that you can make that distinction, and a replacement that > doesn't involve that is a deal breaker for me. > > On 28 December 2014 at 19:46, Jason Merrill <jwme...@gmail.com > <javascript:>> wrote: > >> On Sunday, December 28, 2014 1:34:50 PM UTC-5, Mauro wrote: >>> >>> > Now the popular packages tend use include in a way that's fairly >>> > harmless--i.e. to allow a lot of different symbols and functions to be >>> > exported from a single module, without writing all the code in a >>> single >>> > giant file. But given that the good uses of include are pretty >>> restricted, >>> > I think we'd be better off if the default tool for doing this kind of >>> thing >>> > was more restrictive. >>> >>> Any thoughts on how a restricted include should work? >>> >> >> Sure: we already have modules. The good thing about them is that top >> level code only runs once, and it executes in a separate scope from the >> code where the module is imported. >> >> Modules are great, and you should use one any time you want to run code >> that is in one file from another file. >> >> I can only speculate about the reason that people still use include, even >> though Julia has nice modules. There's a bit about "mixins" in the manual ( >> http://julia.readthedocs.org/en/latest/manual/modules/#modules-and-files), >> but I haven't ever seen include used that way in the wild. The common case >> appears to be that people sometimes want symbols in a "child file" to show >> up in a "parent module". If you make the child file into a module, export >> some of its symbols, and then say "importall Child" in the parent module, >> you get the exported symbols of the child as non-exported symbols of the >> parent. But so far there isn't an easy way to >> >> 1) make all of the non-exported symbols of a child module into >> non-exported symbols of a parent module, nor >> 2) "reexport" all of the exported symbols of a child module from a parent >> module. >> >> 1) feels kind of suspect to me because I think it's better to be explicit >> about these things. But I'd rather see this behavior enabled if it would >> convince people to stop using include, which is much worse. >> >> I'm not sure about names, but 1) could be something like >> >> importunexported Child >> >> which would be like using except that it would load all the symbols in >> Child, not just the ones that were explicitly exported. Even though this is >> not perfectly explicit, it maintains the advantages that the top level code >> in Child is known to run only once, and that it runs in a separate scope >> from Parent so that symbols already in Parent can't affect the behavior of >> top level code in Child. >> >> 2) could be something like >> >> reexport Child >> > >
