simple modules

[Mark S. Miller]

On Tue, Feb 2, 2010 at 10:41 AM, Brendan Eich <brendan at mozilla.com> wrote:

> On Feb 1, 2010, at 7:17 PM, ihab.awad at gmail.com wrote:
>
> Because any object I create in my Context is capable of gaining access
> to the filesystem simply by uttering "import fs", the "fs" authority
> is ambient in my Context.
>
> This is simply not the case. The Context proposal needs to be written
> still, but we have already discussed several times how a Context can have
> its own module id resolver, which can deny "fs" and anything else to the
> would-be importer.
>
> These patterns *are* precisely what is meant when we talk about an
> object capability language. They are precisely what must be supported
> by an object capability subset of an existing language.
>
> JS is not going to *become* an objcap language. The Harmony goal of a
> statically verifiable secure subset is about a subset, not just leaving out
> legacy features we can't get rid of, but possibly also new features added
> for convenience and usability.
>
> The full language is not required to have objcap-only new features. There's
> a related debate in the committee about new sources of non-determinism,
> which is ongoing.
>
> But the point of order I am raising is this: modules for Harmony, and other
> additions to the full set (not the secure subset) are not *required* to be
> object capability language features or patterns, and only objcap features.
>

I'm only now catching up on this thread, so I'm responding out of order to
this one first, and perhaps without sufficient context.

Based on my skimming of the thread to date, I don't think anyone disagrees
with your abstract point. We all agree that only a statically verifiable
subset of Harmony needs to be an ocap language. But this should be a usable
ocap language, not gratuitously lacking any features from full Harmony that
could have been provided safely, merely because Harmony unnecessarily chose
to provide them in an insecurable manner.

In particular, it would be bizarre for Harmony to have two distinct and
disjoint module systems, A and B, simply because module system A was
unnecessarily inappropriate for the ocap subset. Module system B, suitable
for the ocap subset, must also then be in the full language, in order for
SES to *be* a subset. Unless of course B is itself a subset of A.

Since SES needs an ocap-compatible module system, and since this module
system must be within a subset of Harmony, it makes more sense to me to
start with the more constrained problem: Let's design a module system B
adequate for the needs of both SES and Harmony. Once we understand the shape
of that, then we can reexamine whether Harmony still needs a second
insecurable module system, or merely an insecure superset of the secure
module system.


>
> /be
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
   Cheers,
   --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100202/7d5ebfd1/attachment.html>