[e-lang] Designing the E module system (was: A thought on module systems)

[Kevin Reid]

On Aug 29, 2010, at 4:01, Thomas Leonard wrote:

> On 29 August 2010 03:31, Kevin Reid <kpreid at switchb.org> wrote:
>> I think this is an original thought I had about the problem of  
>> modules/
>> libraries:
>>
>>   A module (library) is a stateless unum.
>>
>> Therefore:
>>
>>   Module loading is obtaining a presence of the unum.
>>
>>   Module naming is long-term remote object naming.
>>
>>   Library versioning is an upgrade/protocol-compatibility problem.
>
> By the way, I implemented such a module loading scheme for the ebox  
> demo:
>
>  http://0install.net/ebox.html

Just to get *some* of my thoughts on the matter in writing so we can  
maybe make some progress, I'm going to comment on what I see :

> For example, the "ebox-edit" example application declares a dependency
> on the "ebox-help" library like this:
>
>    <requires interface="http://0install.net/tests/ebox-help.xml">
>      <environment insert="" name="help"/>
>    </requires>

This is good, naming libraries by URLs, and giving the client control  
over how the library is made available. What does the insert=  
parameter mean?

We should not use XML, because XML is designed for document markup,  
and we have a better choice at hand; namely TermL. (Though there is no  
formalized TermL feature serving the role of XML namespaces, yet.)

> This causes a loader for the library to be added to ebox-edit's
> environment (Scope), so that it can import things using e.g.
>
>  def makeHelp := <help:makeHelp>

Does <help> necessarily expose every file in the module as an  
importable item? It should be possible for a module to have private  
components, so that its public interface is well-defined.

What about the module's access to itself? In particular, a module  
should have a reference to its own file tree (as in the <resource>  
loader), or a customizable file-to-object mapping thereof, so that it  
can efficiently store binary data (e.g. images for a GUI library).

> The "interface" URI is both the name of the library and a hint about
> where to get information about it.

Good.

> Incompatible changes use a
> different URI,

Good.

> while backwards-compatible changes just use a different
> version number. Versions can be restricted like this:
>
>    <requires interface="http://0install.net/tests/ebox-help.xml">
>      <environment insert="" name="help"/>
>      <version not-before='1.0' before='2.0'/>
>    </requires>

What is the grammar and ordering of version numbers?

> Downloads get shared automatically, so that if two programs happen to
> use the same version of the same library, then the library only gets
> downloaded and stored on disk once.

It is also important that if there is a diamond dependency

   A requires B --> B requires D
   A requires C --> C requires D

then only one copy of D is loaded into memory, so that B and C have a  
shared vocabulary of objects.

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