Should we relax ocap rules to admit fluid scoping?

4 views
Skip to first unread message

Mark S. Miller

unread,
Jan 12, 2023, 4:44:01 PM1/12/23
to fr...@googlegroups.com, SES Strategy, justin.r...@vercel.com
https://github.com/endojs/endo/pull/1424 contains the code I'll be using to illustrate our discussion about the risk of relaxing ocap rules to admit fluid scoping into an ocap language with Communicating Event Loop (CEL) concurrency. This abstract question applies equally to all ocap+CEL languages, including E, Waterken, Midori, and Endo -- our use of Hardened JS as a CEL language.

The reason this is somewhat urgent is that https://github.com/legendecas/proposal-async-context is a proposed extension to JavaScript currently being made to tc39. Yesterday, at https://www.youtube.com/watch?v=28wfHOWCROo we discussed these hazards specifically in the JS context. Although, really, this discussion as well mostly stayed away from JS specifics. It is a good place to start, but not necessary for my upcoming friam discussion.

For friam, I will use the same code, but explain it assuming less knowledge of JS, and pose the motivating question in a way not specific to JS. Justin Ridgewell (cc'ed), one of the champions of the proposal, may be able to join us, as he did for the discussion at the link above.

Last week, I had proposed doing this presentation tomorrow. But I saw the announcement from Alan that sounds like it may be a conflict. Also, this notice is last minute, for which I apologize.

Alan, is this a conflict? Should I reschedule for a future friam?

--
  Cheers,
  --MarkM

Mark S. Miller

unread,
Jan 12, 2023, 5:01:39 PM1/12/23
to fr...@googlegroups.com, SES Strategy, justin.r...@vercel.com
On Thu, Jan 12, 2023 at 1:43 PM Mark S. Miller <eri...@gmail.com> wrote:
https://github.com/endojs/endo/pull/1424 contains the code I'll be using to illustrate our discussion about the risk of relaxing ocap rules to admit fluid scoping into an ocap language with Communicating Event Loop (CEL) concurrency.

OMG is that a terrible run-on sentence. Also, apologies, I omitted Spritely.

Spritely, E, Waterken, Midori, and Endo -- our use of Hardened JS as a CEL language -- are all ocap languages using Communicating Event Loop (CEL) concurrency. This is different than fine-grain actors (or Joule, or Flat Concurrent Prolog) in that it build on conventional sequential imperative oo programming as a base. Although ocaps can (and have) been added to all of these, the communications possible in the ocaps+CEL languages are different than that possible in ocaps+sequential imperative, and different than ocaps+fine grain actors. It matters what view of time the underlying concurrency model adds to the abstract ocap constraints. Calling "sequential imperative programming" (SIP) a concurrency model though is quite a stretch. Let's consider each of these alternatives as a temporal base -- giving us distinct understandings of how to spread computation out in some sort of "time".

We'll explore first ocaps+SIP+fluid scoping, and demonstrate that the addition of fluid scoping made no safety difference compared to ocaps+SIP.

We'll then explore ocaps+CEL+fluid scoping, and show that it does make a safety difference. But should the result still be considered an ocap language as added to CEL+fluid scoping as a distinct temporal base? Given that we know we're writing code for this ocaps+CEL+fluid scoping, can we still achieve all the safety benefits we currently achieve from ocaps+CEL? I'm going to try to argue "yes". I look forward to your skeptical feedback.

 
This abstract question applies equally to all ocap+CEL languages, including E, Waterken, Midori, and Endo -- our use of Hardened JS as a CEL language.

The reason this is somewhat urgent is that https://github.com/legendecas/proposal-async-context is a proposed extension to JavaScript currently being made to tc39. Yesterday, at https://www.youtube.com/watch?v=28wfHOWCROo we discussed these hazards specifically in the JS context. Although, really, this discussion as well mostly stayed away from JS specifics. It is a good place to start, but not necessary for my upcoming friam discussion.

For friam, I will use the same code, but explain it assuming less knowledge of JS, and pose the motivating question in a way not specific to JS. Justin Ridgewell (cc'ed), one of the champions of the proposal, may be able to join us, as he did for the discussion at the link above.

Last week, I had proposed doing this presentation tomorrow. But I saw the announcement from Alan that sounds like it may be a conflict. Also, this notice is last minute, for which I apologize.

Alan, is this a conflict? Should I reschedule for a future friam?

--
  Cheers,
  --MarkM


--
  Cheers,
  --MarkM

Alan Karp

unread,
Jan 12, 2023, 7:47:06 PM1/12/23
to fr...@googlegroups.com
No conflict.  I decided to let people review the talk at their leisure and just send me comments.

--------------
Alan Karp


--
You received this message because you are subscribed to the Google Groups "friam" group.
To unsubscribe from this group and stop receiving emails from it, send an email to friam+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/friam/CAK5yZYhCPHxVmDCZcWKHF6HY3r7S4VrXgEYuKiUkrXAmviqm%3Dw%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages