endojs / Jessie

Tiny subset of JavaScript for ocap-safe universal mobile code
Apache License 2.0
279 stars 16 forks source link

Confusion regarding Jessie grammar documentation #67

Closed tgrecojs closed 2 years ago

tgrecojs commented 2 years ago

I've arrived at a source of confusion while reading through Jessie's grammar documentation. Specifically, the section on Jessie's functions has me thinking that either the phrase "function functions, arrow functions, and concise method syntax" has been written twice by mistake, or maybe there's a lack of context that the author intended on providing in this section.

Jessie includes arrow functions, function functions, concise method syntax, and accessor (getter / setter) syntax. Jessie omits generators, async functions, async iterator functions in all their syntactic forms: function functions, arrow functions, and concise method syntax. Jessie omits symbols and general computed property access.

The confusion comes with seeing the clause in the initial sentence appear after "syntatic forms:" in the second sentence. Is the intent of this : to inform users that iterators can not be implemented by writing custom implementations of the functions Jessie omits using "function functions, arrow functions, and concise method syntax.".

erights commented 2 years ago

Thanks for this report. We do need clearer language. I'll leave this open until we improve the docs.

To explain here, the issue is that generator functions, async functions, and async generator function each appear in several of these syntactic forms:

function functions arrow functions concise methods getter, setter
function foo() {} () => {} { foo() {} } { get foo() {} }
function* foo() {} none { foo*() {} } none
async function foo() {} async () => {} { async foo() {} } none
async function* foo() {} none { async foo*() {} } none

The point I was trying to make in the confusing text is that the last three rows are absent from Jessie across all the columns.

Currently Jessie does include all four columns of the first row. But we are considering dropping function functions and concise methods, leaving only arrow functions and getters,setters. (We may even consider dropping getters,setters as well, leaving only arrow functions.)

erights commented 2 years ago

Since this doc, we have expanded the definition of Jessie to include async functions, but only under a severe restriction on where await can appear.

See https://github.com/Agoric/agoric-sdk/issues/524 and https://github.com/Agoric/agoric-sdk/wiki/No-Nested-Await

tgrecojs commented 2 years ago

Thanks for this report. We do need clearer language. I'll leave this open until we improve the docs.

To explain here, the issue is that generator functions, async functions, and async generator function each appear in several of these syntactic forms: function functions arrow functions concise methods getter, setter function foo() {} () => {} { foo() {} } { get foo() {} } function* foo() {} none { foo*() {} } none async function foo() {} async () => {} { async foo() {} } none async function* foo() {} none { async foo*() {} } none

The point I was trying to make in the confusing text is that the last three rows are absent from Jessie across all the columns.

Ahh, i see! Thanks for the additional context there. Now, i can re-read the text and get a clear view on what's being expressed.

Currently Jessie does include all four columns of the first row. But we are considering dropping function functions and concise methods, leaving only arrow functions and getters,setters. (We may even consider dropping getters,setters as well, leaving only arrow functions.)

Looking forward to seeing jessie continue progressing. As an avid arrow function user, I have no qualms with leaving function functions behind. 🙂

I'm not sure if there are specific instances where function functions would be needed, but seeing as though there's a focus on eliminating this as well as the use of the maker pattern in exchange for constructor functions, I think that developers might benefit from it being dropped all together as it could make the model a bit more clear, or at least following this model.

thanks again! @erights