At the HPC workshop in London the NetLogo team dropped a hint about NetLogo 7.*, namely improved modularity for NetLogo code (better than .nls files at the momement).
Can you give us more of a preview of what is planned and the timetable?
Thanks
We’re going to be releasing a beta version of NetLogo 7 soon. However, the new module system is currently still in the early stages of development, and we’re not planning to include it until 7.1 at the earliest.
The design of the module system is still subject to change, but here’s a preview of what we currently have.
Suppose you have an NLS file called foo.nls that looks like this.
to hello
show "hello"
end
to world
show "world"
end
You can use the import syntax to include the procedures in the NLS file into your model.
import [foo]
Procedure names will be prefixed with the name of the module, so the procedures in the NLS file will be available as foo:hello and foo:world. This behavior is not set in stone, and we may change it at some point in the future.
You can also control the prefix with the alias option.
import [foo [alias bar]]
With this, the procedures will instead be available as bar:hello and bar:world.
If you have any feedback about this, we’d love to hear them!
That sounds good and is consistent with the existing extensions syntax. It would help a lot - making writing useful modules for others easier and more practical.
Is it planned that one could have modules within modules so one would end with something like foo:bar:thing ?
It is planned that you will be able to import another module from within a module. However, imported procedures will only be visible to the importing module, so wouldn’t normally end up with something like foo:bar:thing. However, you will still be able to re-export specific procedures if you choose to.
For example, if bar.nls looks something like this:
to thing
show "thing"
end
In foo.nls, you can import thing from bar and re-export it by wrapping it in a new procedure like this:
import [bar]
to thing
bar:thing
end
You can then import foo with import [foo], and thing will be available as foo:thing. But for simple cases like this, it would be easier to just import bar directly in the model.
That makes sense as modules should be encapsulated as much as possible (whatever it calls within it).
Any chance of having the documentation for the module being accessible from the main code when coding? (the module documentation 1 level down). This would make for convieniant reference (rather like the info tab coming with NetLogo models).
Thank you for your suggestion. The module system is still in the early stages of development, so we haven’t decided how we’re going to handle documentation yet. I’ll bring this up with the rest of the group.