search

endojs / Jessie

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

Where can I learn more about omissions? #32

Closed christianbundy closed 4 years ago

christianbundy commented 5 years ago

I'm not bringing any pinions to the table, just looking to learn more about Jessie. I've noticed that this and class and other inheritance-based patterns are omitted, which makes sense, but I'm not sure that I understand why async / await were omitted when promises are available.

I'm sure that I have some blind spots in this space, so if there's any recommended reading I should start with I'd love some pointers. Thanks for sharing this project!

erights commented 5 years ago

Good question. I have mixed feeling about omitting async / await. Writing distributed asynchronous code (e.g., much of https://github.com/Agoric/ERTP) without async/await is more verbose than writing it with these. I don't know which leads to fewer interleaving mistakes. I can argue it either way, and we have no objective evidence one way or another. On these grounds, adding async/await to Jessie is tempting.

However, this would conflict with another of Jessie's goals: That Jessie be easy to implement in other common languages as a simple eval/apply style interpreter. JSON caught on largely because it was so easy to write a JSON parser in anything that plenty of people did, and JSON parsers became available everywhere. Likewise, we'd like to see Jessie become a universal language for lightweight mobile code. If the host language has nothing like generators, async functions, co-routines, etc, then there's no straightforward way to implement async/await in those languages.

OTOH, a CPS-transform at await points from Jessie-with-async-await to Jessie-without-async-await would be a target independent transform that could therefore be reused without adding complexity to the target-specific interpreter. Given the self-rehosting plans of https://github.com/Agoric/jessica , this CPS transform could itself be written once in Jessie and then inherited by all platforms running the simple interpreter. So, I would keep it in mind as a possibility for Jessie's possible future. But not until we've closed the loop on such self-rehosting. And probably not until we have better evidence about whether async/await increases or decreases reliability of asynchronous code.