[cap-talk] where(), and a mobile-code JS-over-Python experiment

Tom Van Cutsem tomvc at google.com
Mon Apr 12 18:07:22 PDT 2010


>
>  I think I'd want a convenience shortcut
> in the environment-record construction, though, to make:
>
>  var promise = try(x,y) in (farCompute) {
>   return x+y
>  }
>
> be equivalent to:
>
>  var promise = try(x=x,y=y) in (farCompute) {
>   return x+y
>  }
>

I think that would be perfectly in-line with the current proposal for
destructuring
and patterns <http://wiki.ecmascript.org/doku.php?id=harmony:destructuring>in
ES Harmony.


> > The body of the 'try-in' statement should not contain any free
> > variables (apart from maybe a small set of primordials?), so in
> > principle this code can only communicate with either its originating
> > or its recipient vat through the references that were explicitly
> > listed in the try-in statement's "head".
>
> I think that's an important property (and benefit) of try-in() over
> where(). The where() clause, by capturing references to its free
> variables, makes it awfully easy to accidentally reveal secret or
> sensitive values to the remote Vat. Putting a barrier in place (the
> environment-map (x=exp1,y=exp2) clause) provides a clear visual
> demarcation of what will and will not be revealed to external parties.
>

Indeed. It makes explicit an otherwise (too) hidden
dependency<http://en.wikipedia.org/wiki/Cognitive_dimensions_of_notations#Hidden_dependencies>
.
Another way of looking at it: in lexically scoped languages, the programmer
usually relies upon lexical nesting to strengthen object encapsulation. In
ocap languages like E in particular, lexical scoping is used to attenuate
authority through facets. Outer lexical scopes can usually "trust" inner
lexical scopes. In the case of try-in, we are faced with the peculiar
opposite case: the outer scope cannot "trust" the try-in block to execute as
specified.

As for the primordials, that's tricky. You want the far object to behave
> predictably. There are a set of objects that all E programs have access
> to (basic data types, etc). A very strict try-in implementation would
> obligate the programmer to declare their intention to grant access to
> even these built-in objects, by including them in the environment-map.
> An easier-to-use one would say that everything available to all E
> programs (say, the environment that exists on the first line of the
> program) is also available to the remote code. The difference between
> the local implementations of these objects and the remote host's
> versions is probably important to keep track of.
>

I think from a usability perspective it's important to provide the try-in
block with at least the "primordial" functionality that it could expect as
if it were executing in the top-level scope of a fresh execution context. Of
course, we are thinking in terms of the "Secure Ecmascript" (SES) subset of
Javascript, in which all globals are frozen (so a try-in block from vat A
can't monkey-patch vat B's primordials).

I'd also compare when() and try-in() on the basis of how the
> objects-revealed-to-remote-Vat are made visually obvious. A reviewer
> needs to be able to tell what is kept locally and what is revealed to
> others. The try-in clause looks a little too much like a normal
> try-catch clause (you'd want your editor's syntax-highlighter to make
> that "in" keyword really stand out), but at least all of the revealed
> references are contained on a single line next to the critical "in"
> keyword. The where() clause is more distinct (the "where" keyword is on
> the left edge, whereas "in" is buried somewhere in the middle of the
> line), but then it takes a lot of manual inspection to figure out which
> references are being revealed.


When we came up with "try-in", one of our design constraints was that we had
to stick with existing Javascript keywords (+ those on the reserved keywords
list).
It is possible to introduce 'where' after the 'try' keyword:

try where (x = ..., y = ...) in ( computer ) {
  ...
}

However I don't think it's really necessary. Unlike in a traditional "try"
statement, in the "try-in" statement the "try" keyword is never immediately
followed by an open curly.
And, as you point out, visibility issues can be addressed through syntax
highlighting. I agree that syntax-highlighting the entire try-in body would
be very useful.

Cheers,
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20100412/719d161f/attachment-0001.html 


More information about the cap-talk mailing list