[e-lang] Kevin's thoughts on modules

[Kevin Reid]

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>".  
Goals:

   - 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  
part of
     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  
in it.

Whatever actually gets done should exist directly in E  
implementations, not be an outside library, of course.

-- 
Kevin Reid                                  <http://switchb.org/kpreid/>