[e-lang] Kevin's thoughts on modules
kpreid at switchb.org
Sun Apr 10 19:08:33 PDT 2011
My rough ideas for a module system include these goals/characteristics
which are notably different from emakers:
* No global namespace as in Java classpaths. (In Java, only convention
prevents a .jar from stepping on any name it wants to; this should be
*inexpressible* in a capability system.) Instead, once a 'module' has
been identified, it has its own namespace which is free to be entirely
flat (or not).
* It should be possible to identify a module in a highly future-proof
way, and have it automatically downloaded if needed. In particular, it
should be easy to say "def myModule := <load the code which has the
SHA-whatever hash code 324587.... plus the following locator hints>".
- that it be rare that one wishes to cut-and-paste code (without
modification) rather than loading it as a module.
- that there is little barrier to using libraries which are not
standard E distributions.
It would also be nice to, while being all nice and integrated about
module downloading, avoid inventing the equivalent of another package
installation system (CPAN, ruby gems, py-
whateverthey'redoingthesedays, quicklisp, etc.)
* A module should be able to have private shared objects while its
implementation is broken across multiple files. (In the emaker system,
everything is either public or local to one .emaker file.)
* A module should be able to efficiently contain objects which are
unserialized (in the most general sense) data (e.g. images) without
exposing the distinction between these and code to clients.
There are probably other requirements I haven't remembered of just now.
Open questions is when modules should be instantiated (is there one of
a given module per vat, or not?); if they can be multiply
instantiated, whether that's 'deep' or 'shallow' wrt dependencies
(where do you stop?); and how to support (if at all) modules or graphs
of modules being granted references to privileged/application-specific
objects. (It would be nice to say that a module is always
unprivileged, but that results (I think) in certain types of
applications requiring massive application of the Author pattern,
which is undesirable in my opinion.)
The last time I was thinking about this, I actually wrote some code;
see the darcs repository at <http://switchb.org/darcs/e-modules/>.
This is not a complete system and probably has some design flaws in
its module format; but it works enough that I successfully loaded Den
Whatever actually gets done should exist directly in E
implementations, not be an outside library, of course.
Kevin Reid <http://switchb.org/kpreid/>
More information about the e-lang