Alternate proposal for a better module system

[trans]

This is my second proposal for a better module system for Julia. Reading my first proposal (#8014) will be helpful in understanding this proposal. This proposal has the same goals as the first, but unlike the first is simpler and consequently has some limitations --but it may be that those limitation are not significant ones.

What this proposal does is equate modules and files. Thus there is no need to declare module Foo in a file. So that's convenient. But is also means that no file can have more than one module defined in it. For the sake of clarity I will call these module-files so not to confuse them with the terms of the first proposal.

Loading a module-file and using a module-file is one and the same action.

# Bar.jl
export b
function b()
  ... 
end

# Foo.jl
import Bar
function f()
   b()
 end

And just like that all of Bar's exported functions are available to Foo. We can of course load specific functions as before.

# Foo.jl
import Bar: b

To get the an "absolute" handle on a module we assign it.

# Foo.jl
Bar = import Bar: b

"Reopening" a module is a little trickier in this proposal, but it should still be possible via an absolute handle. e.g.

Bar.export("q")

Interestingly however, this could be made to effect only a local "version" of Bar vs all imports of Bar. That question is left open.

Loading files works as in the first proposal. Local files are searched first, and then packages, unless a package is clearly specified, e.g.

module Foo
  import Bar|Bar
end

The exact syntax of | not withstanding.

This proposal is clearly much simpler than the first. In fact, it is probably as simple as a module system can get, which is kind of nice. It does have some limitations, in particular that each module must be define in it own file. But that may actually be a benefit as it make it very clear where code resides.

[StefanKarpinski]

The file = module requirement is not good. Matlab's file = function restriction is generally acknowledged to be terrible and leads to bloated functions and/or too many small files. Java's file = class arrangement is better in as much as classes may contain many functions, but it's still pretty annoying. Doing file = module is only better than these in as much as modules are coarser than classes and functions, but it's still problematic. You may want to split a large module over many files. It's less common, but you may want to have multiple modules in a single file. How would you create modules at the REPL? This makes examples involving modules hard to express or work with.

[jkroso]

file = module doesn't need to be a restriction at all. Its what the node.js community uses and its very very common there to write a module thats has submodules or is split into several files. And there is no reason why you shouldn't be able to write submodules inside of module-files or at the repl just the way its currently done. And to prove it, here it is. My dream module system already working seamlessly on top of the existing one.

[IainNZ]

@jkroso that looks interesting, I've just made https://github.com/jkroso/Require.jl/issues/1 to try to understand your system more.

[trans]

@jkroso That does look very interesting! I wondering a bit about the way lookup works, but I need to study it a bit more to really discuss. In any case, very very promising!!! And it's damn cool that you actually implemented it 👍

[jkroso]

@trans yea It came out better than I had hoped. I even like the macro syntax better than julia's built in import syntax. Unfortunately at this point it looks like I haven't done a very good job of the Readme so let me know if you think of any ways to improve it

[StefanKarpinski]

That's a cool experiment, @jkroso – thanks for posting it. The biggest problem I have with anything = file paradigms is that it makes it basically impossible to use whatever construct is tied to a file in an interactive setting. Want to define a function in Matlab? You have to create a file. Want to define a class in Java? You have to create a file. Well, in Java, it doesn't matter that much because there's no decent REPL and the IDEs are basically artificially intelligent. So if you can come up with a clever way to allow creating modules in the REPL without having to create a file and similarly create multiple modules in a single file, then that would make this a lot more palatable.

[jkroso]

I think the modules Julia has are good I've just changed the way they are loaded and installed. Now I think everything is perfect. Everything should continue to work fine at the REPL.

[JeffBezanson]

@jkroso very nice work! I especially appreciate your in-hindsight-obvious observation that file-modules and syntactically-delimited modules aren't mutually exclusive. I agree we could do with some load-and-path-related tweaking. Some of these ideas are very good candidates for changes to the built-in module system.

[trans]

This might be of interest, in general: http://isocpp.org/files/papers/n4214.pdf