Planning: Dynamic Module Loading

StardustPL / Stardust

"A programming language that doesn't make me angry to use it."

https://StardustPL.GitHub.IO/

The Unlicense

4 stars 0 forks source link

Planning: Dynamic Module Loading #18

Open LB-- opened 9 years ago

LB-- commented 9 years ago

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.

LB-- commented 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.

LB-- commented 9 years ago

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.

LB-- commented 8 years ago

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:

DLL-like usage: load a module one or more times at runtime, possibly with different parameters
Shared object-like usage: just pass the module namespace to other modules
Statically linked libraries: just load the module at compile time and pass in all the dependencies
Statically linked DLLs: just load the module at compile time and that module will already have all the dependencies it needs statically linked
various combinations of the above, etc

LB-- commented 8 years ago

Python has eggs. Ruby has gems. How about Stardust has nebulas. *.stardust-nebula

LB-- commented 8 years ago

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.