[e-lang] E patches for review: ELoader, FileGetter

[Thomas Leonard]

On Tue, 2010-05-04 at 10:20 -0400, Kevin Reid wrote:
> On May 4, 2010, at 7:14, Thomas Leonard wrote:
> 
> > I've committed the SecureRandom change now. Next up:
> >
> >
> > Allow uncalling deep and shallow ReadyOnlyFile objects:
> >
> > http://gitorious.org/~tal-itinnov/repo-roscidus/it-innovation/commit/b17bc51fe586b6eabcedfe4d46da5b0a65b65428
> 
> Code looks good, except that I would make the method something less  
> generic than "isTransitive"; it should be a name which is  
> appropriately specific within the context of the overall File  
> protocol. Perhaps it should be a 3-valued return, distinguishing read/ 
> write and shallow and deep read-only? I haven't looked to see if there  
> is any existing interface covering RW/RO.

There isn't, the existing code matched on type (File vs ReadOnlyFile).
Also, such a method might be confused with the OS's notion of a
read-only file. I've renamed the method to isDeepReadOnly:

http://gitorious.org/~tal-itinnov/repo-roscidus/it-innovation/commit/fb357321126906930f706374825d035c4f86ddf8

> Also, please add *specification* text to wiki.erights.org (following  
> the existing examples of documents in <http://wiki.erights.org/wiki/Category:E_specification 
>  >, and using the appropriate templates) for anything you add to the  
> public interfaces of core E objects.

OK, once it's in svn.

> > ELoader:
> >
> > http://gitorious.org/~tal-itinnov/repo-roscidus/it-innovation/commit/ae8f337328aa0bbbf5d9a9cb565866fe3fff975d
> >
> > http://www.eros-os.org/pipermail/e-lang/2010-February/013416.html
> >
> > ELoader now provides an __optUncall and, just to make it obvious that
> > envExtra isn't private, there's an explicit getEnvExtras/0 too. This
> > should make it easier to spawn new vats with the same set of modules,
> > but I haven't updated seedVat yet.
> 
> I object to including ELoader in E-on-Java because it does not go far  
> enough.
> 
> Most significantly with regard to the design, we need a system which  
> allows defining modules in terms of multiple source files which share  
> *private* state. Right now, any objects which must share private state  
> (e.g. an unsealer) must be defined in the same .emaker (because  
> anything exported by an emaker is visible to the entire vat), which is  
> a bad situation for writing well-structured code.

Can this be handled by creating a top-level .emaker in the module? e.g.

# instance.emaker
def sharedState := <this:makeSharedState>()
[
  "foo" => <this:foo>(sharedState),
  "bar" => <this:bar>(sharedState)
]

Then to use it:

def <instance> := <module:instance>
<instance:foo>(...)
<instance:bar>(...)

Note: Doing <module:instance> again will create a second configuration
(that's a feature: no singletons!). Also, you'd probably want to use
makeLazySlot to load the sub-components on demand.

You could put sharedState in each file's top-level scope, e.g.

# instance.emaker
def sharedState := <this:makeSharedState>()
def <loader> := makeELoader(<this>.getRoot(),
                   [ "this__uriGetter" => <loader>, => sharedState ],
                   "mymodule")
[
  "foo" => <loader:foo>,
  "bar" => <loader:bar>
]

However, you'd then need to be careful not to expose <loader> anywhere
in any file in your module, which seems risky. I'm having enough trouble
trying to get loaders to uncall safely already (without giving up
makeTraceln).

> In general, there should be a separation between "what are the  
> 'exported symbols' of this module" and how they are laid out on disk  
> -- *optionally*. The default should be to map symbols to files because  
> that is convenient, but other structures should be possible.
> 
> Other features which are desirable in a module system, but can  
> probably be added later, are references to (dependencies on) other  
> modules,

This we already have ;-)

> and metadata including the version of the safeEnv (or  
> whatever) the code in the module expects to be evaluated in. (This is  
> so that we can in the future safely revise the E design in ways  
> including deleting now-seen-as-clutter safeEnv members.)

Would be nice. Couldn't the version pragma do this though?


-- 
Dr Thomas Leonard
IT Innovation Centre
2 Venture Road
Southampton
Hampshire SO16 7NP

Tel: +44 0 23 8076 0834
Fax: +44 0 23 8076 0833
mailto:tal at it-innovation.soton.ac.uk
http://www.it-innovation.soton.ac.uk