- Where: zoom.us
- When: August 18th, 4pm-5pm UTC (August 18th, 9am-10am Pacific Daylight Time)
- Location: link on calendar invite
None required if you've attended before. Send an email to the acting WebAssembly CG chair to sign up if it's your first time. The meeting is open to CG members only.
The meeting will be on a zoom.us video conference. Installation is required, see the calendar invite.
- Opening, welcome and roll call
- Opening of the meeting
- Introduction of attendees
- Find volunteers for note taking (acting chair to volunteer)
- Adoption of the agenda
- Proposals and discussions
- Review of action items from prior meeting.
- A Meta-meta-meta Request for Proposals (7.5 minutes)
- Discussion on Typed continuations for stacks (issue) (Daniel Hillerström, Daan Leijen, Sam Lindley, Matija Pretnar, Andreas Rossberg, KC Sivaramakrishnan) [20 min]
- Poll: Phase 1?
- Proposal for changes in EH proposal for two-phase unwinding support +
discussions (Heejin Ahn) [25 min]
- Potential poll: Should we make the change?
- Closure
None
None
- Adam Klein
- Alexander Syrotenko
- Alex Crichton
- Alon Zakai
- Andreas Rossberg
- Asumu Takikawa
- Ben Smith
- Conrad Watt
- Dan Gohman
- Daniel Hillerström
- Daniel Wirtz
- Derek Schuff
- Emanuel Ziegler
- Francis McCabe
- Heejin Ahn
- Ioanna Dimitriou
- Jakob Kummerow
- Jay Phelps
- Jlbirch
- KC Sivaramakrishnan
- Keith Miller
- Lars Hansen
- Luke Wagner
- Nick Fitzgerald
- Paolo Severini
- Pat Hickey
- Paul Dworzanski
- Rick
- Ross Tate
- Ryan Hunt
- Sam Lindley
- Sergey Rubanov
- Syvatoslav Kuzmich
- TatWai Chong
- Thomas Lively
- Till Schneidereit
- Vivek Sekhar
- Wouter Van Oortmersson
- Yury Delendik
- Zalim Bashorov
- Zhi An Ng
Lars seconded
Francis McCabe presenting Slides for RFP Proposal
AR: What are the differences between our current process. It seems like phase 0 is similar, one or two pages. At that point CG votes if they have interest, which is phase 1. What's the difference with RFP?
FM: new artefact, the RFP itself, it will morph into a requirements doc. Having a separate reqs doc where you state what you want. Not that different from what we do informally, I'm proposing we formalize it to some extent.
CW: The biggest difference is if someone "misses the boat" then that would be ground to reject their proposal out of hand.
FM: we have seen some of these already, it has caused a lot of trouble, e.g. with exception handling, garbage collection. We’ve seen late proposals, even though they should be given more space, they haven’t been given more space (informally). This has caused a lot of friction
AR: The particular examples you gave are things we voted on in the CG years ago. How would these particular examples change with what you propose. Exceptions have been at phase 2 for a while, before most recent discussions were started.
FM: it does have a forcing function, that’s part of the point. Part of the reason behind this is to do that: it is to make the bar higher for people coming later
BS: have to cut off discussion here, can come back to this at the end of the meeting or follow up on an issue.
Discussion on Typed continuations for stacks (issue) (Daniel Hillerström, Daan Leijen, Sam Lindley, Matija Pretnar, Andreas Rossberg, KC Sivaramakrishnan) [20 min]
[TODO(AR): add link to slides]
HA: What does undelimited continuation look like? Are synchronous continuations…
AR: Undelimited means you don't have a parent. You can't do that, you can invoke another continuation. So call/cc, in scheme, that implements undelimited continuations, they're symmetric.
HA: Thanks
[Back to slides]
RT: You say in practice you want delimited continuations, but Python's stackless continuations are undelimited. A lot of people use this. I understand you can emulate this, but this is a pretty popular system that uses this.
AR: Right, but it's true that if you talk to scheme folks they say you don't really want this.
RT: for applications, custom control structures, delimited control is preferable, for other applications, such as green threads, undelimited is more common, depending on setting.
AR: control abstractions is what we are targeting here, that’s the whole point of the proposal, that’s why you want stack switching. You want stack switching to compile control abstractions. Almost all are of this nature
RT: Python want's stack switching for green threads.
AR: one of the few control abstractions you can actually implement with undelimited continuations but not in a compositional way.
[back to slides]
<On note about “avoids GC”>
RT: should bring this up offline in the discussion of the other proposal, not spring a surprise like this
AR: yes, point is by construction, avoid GC
RT: the other proposal also does not have cycles by construction
[back to slides]
FM: I want to pick apart the typed part of this… if you have two coroutines communicating through a channel, then there is flow information not known to the scheduler. When you talk about types, you're only talking about communication between a thread and its scheduler.
AR: between stack and its parent
FM: talking about green thread scenario, it’s between thread and scheduler. The types you’re talking about here are only the types.. Only the “control types” of the thread itself, not any data being communicated. OTOH, I will assert that the programmer is most interested in the type going through the channel.
AR: The types here are only concerned with what the construct does. If you have other channels, with which threads can communicate, this is agnostic to that. But it is still the case, as with await or generators, these are the values you want to communicate with. You are communicating specific values between the thread and the generator, etc.
FM: when the stack is deciding to signal back to its parent, there are different scenarios that might happen, normal, exceptional, yield, some data. These are variants of a control flow, there isn’t one type involved here, since each of these different events have different type information associated with it.
AR: That's crucial right. Different suspend points and have different types. With await that's exactly what you need.
FM: but you call out one of them, which is the final return values. If you have a coroutine (using this to be general), if it never suspends, then you’re probably not using the control mechanism, it will suspend at least once. A non-normal return will happen more often than normal return, but you called out normal return in the type. I will argue that is meaningless…
AR: you’re right, but i’m not talking about normal returns, the resume and return is typed.
BS: unfortunately, have to cut off to move on to next topic. Can come back to this at the end. There’s a lot more to talk about this, especially with the other proposal.
Proposal for changes in EH proposal for two-phase unwinding support + discussions (Heejin Ahn) [25 min]
Slides: Two-phase Unwinding and its Implications
AR: Why is it not a simpler transformation to move callB out of the inner try? It's probably worth noting that this example is over-simplified, but in the general case it's not so simple.
HA: Yes, in whatever way we sort the CFG we can solve this problem.
AR: iiuc, that comes in when you have multiple unwinds going to the same handler, if you didn’t have that, this problem wouldn’t exist, the CFG might construct such a thing
HA: Not sure, in the original program callA and callB should unwind to different catches. It's a byproduct of CFG linearization that we end up in the inner try. But that's not the program's semantics. So we're fixing it to use the original program's semantics by using transformations.
ID (on chat): sorry, no microphone, couldn't one also use br_on_exn there? I mean, instead of setting a local with the exnref
HA: br_on_exn is for checking tags, this is for how we can find the right catch. Br_on_exn is used after we determine which catch we should go to. After we decided if this is the right catch, we use br_on_exn for tag checking. Btw, we don’t need to use locals here. We can make block return value, setting local is a simple way to do it. The gist of this is that exnref can escape catch blocks, we can do this transformation behind the scenes.
BS: We're out of time. Let's continue discussion on the issue.