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

Kevin Reid kpreid at switchb.org
Mon May 24 06:51:35 PDT 2010


On May 4, 2010, at 11:35, Thomas Leonard wrote:
> On Tue, 2010-05-04 at 10:20 -0400, Kevin Reid wrote:
>> 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>(...)

[Sorry, I forgot to note to reply to this message.]

The problems with this method are:

   - <module:instance> is inherently misnamed; the result of a <>  
expression should not *logically* be a new anything. That should be  
reserved for things named makeInstance().

   - Implementation details are exposed as <module:foo>.

   - There is an indirection exposed to the user that they don't have  
reason to care about; a client should not have a procedure to load a  
module differently if it does not happen to have any 'shared  
concepts'. (I should clarify that I agree that there-are-no- 
singletons; I just think that the *default* module-loading protocol  
should permit modules to instantiate shared DeepFrozen objects.

>> 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?

The version pragma is strictly syntactic; it is gone after parsing.

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






More information about the e-lang mailing list