Closed warner closed 2 years ago
Another hazard of functions vs arrow functions. A Jessie module should only be able to export objects that have no transitively reachable mutable state, i.e., are pure in the sense of Wyvern's module system. With arrow functions, we can require code such as
export const foo = def((...args) => body);
For function
functions, we'd like to be able to write
export function foo(...args) { body }
def(foo);
however, in the context of cyclic imports, foo
could be accessible before it is frozen. The safe alternative
export const foo = def(function(...args) { body });
is substantially more verbose than either. Programmers (including myself) will be esthetically repelled by code containing that last form. If Jessie does have function
functions, we need to find a better way to export a safe one.
I am about to transfer this issue from the SES repository to the Jessie repository. Issue transfer is a Github beta feature and I've never done it before, which is why I'm making this note first.
We are in the midst of designing better rules for writing modules to be used as pure modules. We will require only that the module is purifiable, i.e., that it becomes pure, if all of its imports are pure and all its exports are hardened. We assume that a purity-enforcing loader will do the harden
calls on the exported values. As a result, code like
export function foo(...args) { body }
is perfectly fine code for a pure SES module without this module having to explicitly harden foo
. By exporting foo
, we get that effect for no further notation.
The remaining issue with allowing function
in Jessie is whether a SES caller of a Jessie function can cause mischief by invoking it with new
. I believe the answer is that allowing this causes no loss of security. All the mischief that the SES caller could do by these means, they can do anyway.
Given this, I think the right thing to do is to include function
in Jessie. Since function
is already included in the current Jessie grammar, I am closing this.
Reopening. I forget that Jessie supports only default exports, so the reasoning above is flawed.
This is very strange. In email I got notified of two messages in this thread from Michael Fig, sent at 8:20pm and 8:21pm Jan 9 2019. But when I refresh this github thread page in my browser, the last message I see in this thread is one from me six days earlier.
Any ideas?
Now I see that Michael also posted these as https://github.com/Agoric/Jessie/issues/19 , so I'll answer there.
@erights wanted me to file a placeholder ticket, to remind us to think about how Jessie and SES will interact with non-arrow-functions. I think we're still undecided about whether Jessie should provide only arrow functions, or if it should offer traditional
function NAME(ARGS) { }
too. Arrow functions don't provide constructor behavior, so the risk of offering traditional functions is that they could be called from SES withnew
, which might cause surprises (Jessie forbids bothnew
andthis
, so Jessie code couldn't provoke this, but it could happen if SES code is given access to a Jessie-defined object). The fact that Jessie rejectsthis
might limit the surprises to ones that the SES code could have built anyways.I'll leave it to @erights to fill in the details.