Jacaranda and modules

[ihab...@gmail.com]

Hi folks,

Jacaranda is a statically verifiable secure JavaScript variant by
David-Sarah Hopwood (cc:'d). The following is the latest complete spec
--

http://www.jacaranda.org/jacaranda-spec-0.3.txt

Mark Miller (cc:'d) brought to my attention the fact that it has
interesting insights about modularity. To get to the start of this
discussion, search in the above text for the string --

Jacaranda programs are organised into *modules*

Ihab

--
Ihab A.B. Awad, Palo Alto, CA

[Kris Kowal]

On Mon, Jan 19, 2009 at 10:17 AM, <ihab...@gmail.com> wrote:
> Jacaranda is a statically verifiable secure JavaScript variant by
> David-Sarah Hopwood (cc:'d). The following is the latest complete spec

> http://www.jacaranda.org/jacaranda-spec-0.3.txt

Are Jacaranda parse trees purple in Spring?

I think that the definitions here closely resemble our specification.
http://docs.google.com/Doc?id=dfgxb7gk_34gpk37z9v&hl=en

(Jacaranda -> ES Module Proposal)
* "module name" -> "module identifier"
* "module definition" -> "module text"
* "internal module representation" -> an object that contains the
"module instance" and (I presume) metadata
* "caplet" -> "module instance"
* "environment" -> "sandbox"
* "powersource" -> capabilities, or "params" currently

Probably the main distinction between our proposal and Jacaranda, or
Caja for that matter, is that the verifier requires that modules be
written effectively in our "desugarred" syntax. There are some
distinctions from our current desugared syntax, though, that I think
are worth noting and perhaps adopting.

Jacarta:
module(function ($_) { with ($_) { return {...}; }});
Modules:
function (require, exports) {...; return exports};
Chiron (paraphrased):
function (imports, exports) {
with (imports) { with (exports) {
(function () {
...
})();
}}
}

The explicit call is necessary in Jacarta for reasons irrelevant to
us. $_ is a scope into which imports are written. This is almost
equivalent to Chiron's modules.js. However, we've avoided this use of
a with block by desugarring "import X as Y" to "let Y = require(X)",
so we just use the function local scope for imports. However, we have
the exact opposite problem with exports, particularly for our salty
syntax. Currently, our salty syntax for exports looks like:

> let foo = exports.foo = ...;

For the sugar:

> export foo = ...;

Both syntacies bring "foo" both into local scope and exports.
Ideally, our salty syntax would be:

> exports.foo = ...;

To quote the Jacarta spec:

> We could alteratively have required something like:
> (function(imports) {
> /*const*/ var foo = imports.foo,
> bar = imports.bar,
> ...;
> ...
> })();
> but this would be far too verbose, and would violate the
> "Don't Repeat Yourself" principle since each import name is
> mentioned twice.

I think we should consider using a "with" block in the desugared
syntax to bring exports into local scope. If we do this, we should do
it the Chiron way, not the Jacarta way, because Chiron accounts for
browser bugs in interactions between closures and "with" blocks.
Using a closure inside the with block resolves those problems:

function (require, exports) {
with (exports) {
(function () {
...
})();
}
}

I'm still unclear about how "powerbox" and "powersource" work, but I
think they amount to a desugared syntax for requesting imports.

[ihab...@gmail.com]

Haven't read up on everything but --

On Mon, Jan 19, 2009 at 1:03 PM, Kris Kowal <cowber...@gmail.com> wrote:
> (Jacaranda -> ES Module Proposal)

> * "internal module representation" -> an object that contains the
> "module instance" and (I presume) metadata

I think it's more like --

* "internal module representation" -> module function