non-arrow functions vs Jessie

[warner]

@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 with new, which might cause surprises (Jessie forbids both new and this, 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 rejects this 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.

[erights]

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.

[erights]

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.

[erights]

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.

[erights]

Reopening. I forget that Jessie supports only default exports, so the reasoning above is flawed.

[erights]

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?

[erights]

Now I see that Michael also posted these as #19 , so I'll answer there.