simple modules

[Sam Tobin-Hochstadt]

On Mon, Feb 1, 2010 at 1:04 AM, <ihab.awad at gmail.com> wrote:
>
> Hi Sam,
>
> On Sun, Jan 31, 2010 at 6:56 PM, Sam Tobin-Hochstadt <samth at ccs.neu.edu> wrote:
> > First, it's also possible to achieve isolation via lexical scope by
> > using functions, closures, and objects, as Dave's example shows.  Our
> > proposal attempts to leverage the existing facilities in EcmaScript to
> > achieve most of isolation, using modules for name management and
> > restricting the top-level lexical environment.
>
> But, in some module M that imports X, Y and Z, the top-level lexical
> environment *must* include access to all the state encapsulated by X,
> Y and Z.

That's only the case if X, Y, and Z provide access to their internal
state via the bindings they export.  For example:

module MemoFun {
  var table = {};
  export function f(x) {
    if table[x] { return table[x]; }
    // imagine complex but pure computation here
    var tmp = x + 7;
    table[x] = tmp;
    return tmp;
   }
}

Here, the only access provided to the state is via the function `f'.
Outside modules cannot disturb the invariants of the code at all.

> > Second, we expect that needing to isolate untrusted code is the
> > uncommon case for importing a module.
>
> That is only true if you *completely* trust all the code you and all
> your coworkers write on a large project. Otherwise, the issue is not
> isolating untrusted *code* but isolating the extent of authorities
> into code. This is important for both security and software
> engineering.

It has been my experience that most of the isolation needed between
modules can be accomplished by lexical scope.  For example, in the
MemoFun module, the function `f' doesn't have to trust any other
modules that it might import (or that might import it) to avoid
interference with its invariants - lexical scope takes care of that.


> > So, the way I think of it, everything in our proposal is internally
> > linked, except insofar as a Context might specify a different behavior
> > for the name of some module.
>
> So you propose linking to a standard library using some agreed-upon
> name. Let's say it's "stdlib". So, when I say:
>
>  import stdlib;
>  /* ... my code here ... */
>
> If "stdlib" were some reference to some code which I could make more
> or less independently of the container (perhaps subject to its
> permission, but not too much else), then this is internal linking.
> However, if "stdlib" is not only some code but an object *with
> expected powers* that the container must be expected to set up for me
> ahead of time, that sounds like external linking.
>
> Am I incorrect in my use of the terms?

I would normally say that a module that imports the standard library
in that fashion is internally linked.  To take a different language,
import in Java is internal linking, even though the meaning of names
can be rearranged via the classpath (or via the filesystem).  But
given that we always have the power to change the environment the
program operates in, the boundary between internal and external
linking can become fuzzy.

> In any case, my point stands. The namespaces for "pure code being
> brought in" and "powers granted to me by my container" are being
> conflated. For the former, you need modules. For the latter, you need
> some sort of "service registry" or whatever else.

I think that in many cases, conflating these two concepts is
appropriate.  For example, if I import jQuery to add some simple bit
of functionality to my homepage, I almost certainly want to give it
access to all of the things I have access to.  This is the common case
that our strawman tries to make simple.  However, in other contexts a
service registry may be more appropriate, and that can be built on top
of modules, using either the dynamic loading features, or simple
lexical scope with functions and objects.

--
sam th
samth at ccs.neu.edu