Open LB-- opened 9 years ago
When a module primitive is destroyed it will try to unload the module. If any types or other things from the module are still being referenced, an exception will be thrown and the module will not unload.
Not sure what I was thinking. This is a horrible idea - destructors should not throw. This needs to be thought out more.
It looks like most if not all 'special' things in the language, like types, functions, namespaces, etc. will be reference-counted/garbage-collected. So, really, a module's lifetime should not be confined to scope - it'll probably just be a namespace returned from a function.
I think I like a looser definition of modules - loading a module just returns the module's namespace. The parameters to the module are the parameters to its namespace. Modules can be loaded multiple times with different parameters. All the types, namespaces, functions, etc. are kept in the code at compile time. This allows fro three kind of usages:
Python has eggs. Ruby has gems. How about Stardust has nebulas. *.stardust-nebula
It should probably be made as easy as possible to download modules from e.g. git repositories and other VCS, to help with managing dependencies. Given a URI like https://github.com/StardustPL/blah.git
and either a tag name or commit hash, the repository will be downloaded and cached and then be imported as usual. Branch names can't be used because this has no means of versioning.
Example pseudo-code:
module blah-module := import-module("https://github.com/StardustPL/blah.git", "v0.1.2") //make sure we use v0.1.2
namespace blah := blah-module(args) //instantiate the module with args
namespace blah-different := blah-module(args-different) //instantiate the module with different args
Using local modules seems like it would be a less common thing and would be primarily used for closed-source projects.
External modules may be loaded at both compile time and runtime. A module object primitive allows access to the contents of the module via the
:
operator (the module contents is not shoved into the global scope). As such, modules may be loaded multiple times (either different versions, or the same version).Modules with dependencies of their own may wish to use delayed loading - this way, if the dependency is already loaded by the parent, it can be explicitly shared. This avoids infinite recursion with circular dependencies, although module recursion may still be a useful tool in (extremely rare) cases.
When a module primitive is destroyed it will try to unload the module. If any types or other things from the module are still being referenced, an exception will be thrown and the module will not unload.