- Where: zoom.us
- When: August 6th, 4pm-5pm UTC (August 6th, 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.
- Discuss NSF Expedition on WebAssembly
- Discuss new proposal that introduces types for modules and instances (and text format thereof), as initially discussed in design/#1289 (slides)
- Closure
None
None
Derek Schuff Luke Wagner Sam Clegg Ross Tate Francis McCabe Bill Ticehurst Deepti Gandluri Alon Zakai Rrwinterton Till Schneidereit Dan Gohman Peter Jensen Pat Hickey TatWai Chong Andreas Rossberg Luke Imhoff Conrad Watt Zhi An Ng Alex Crichton Jacob Gravelle Arun Purushan Thomas Lively Ryan Hunt Lin Clark Adam Klein Shiv Kushwaha Sven Sauleau Jay Phelps
Luke Imhoff seconds.
Ross Tate[RT]:
Thinking of preparing NSF Expeditions grant proposal for wasm. Large grant, requires a lot of collaboration. Letters of collaboration from wasm team expressing interest in collaboration. NSF Expeditions have to be big expeditions, letters of collaboration needed from each browser probably. Application due in April.
FM: What’s the aim of the project?
RT: First thing is helping with the GC proposal - shared garbage collector with the rest of the proposal, so that DOM
DG: what would you be looking for from the community beyond letters of collaboration?
RT: the idea is that we commit to spend some time helping them make it happen. I.e. someone who works on the GC on at least one of the browsers, who can give insight on the challenges, etc. feedback on feasibility.
FM: Is there a history of NSF supporting this?
RT: both of our previous NSF grants were like this. One was collaboration with Kotlin and [??]. Another was with the Julia team. Response was that they wanted to accept but couldn’t do it withgout the letter. So there’s a history of NSF support of this, and of this formal commitment actually mattering.
LW: In the scope of the work, is there implementation work required? Either for the spec, or for prototyping?
RT: NSF has historically not been very interested in funding development to that degree. So a second thing we’re looking that is….
Timeline is that we don’t get the money for 2 years. It should be spent on research (e.g. students, postdocs, event attendance) and educational aspects. E.g. courses, training, e.g. about how to implement compilers for wasm etc. But in this setting the development involves a big research component. E.g. how to make a managed language communicate with a browser’s GC etc. So NSF covers that kind of thing.
For the development side, looking into an initiative - make a webpage, with interested folks, companies interested in encouraging research sign up for membership - we have discretionary use of funds. They basically act as the bank for this, there is overhead, but not more than if it was a gift. Goal is to get that in place, to get funding at a faster pace, if the expedition doesn’t go through - plan is to split it up and apply through smaller mediums
LW: for development there’s a spectrum. There’s early prototyping which is essential for any spec, vs polish. Could that kind of prototyping fall under the research and be funded?
RT: could be. The proposal needs to say how we will evaluate the research, and that could be part of it.
DG: I can facilitate some offline conversations on our side. For this meeting, are there any objections from the community to doing this kind of research?
… [no objections raised]
RT: there are 2 things that would be helpful. On is breadth. So interest from the browsers. But also from folks who would be producing compilers targeting wasm. The other thing is breadth of expertise. E.g. in other aspects of the web and [?]
For some of these, a letter from the CG itself could be useful.
RT(in chat): Other researchers (and specialities) currently involved: Arjun Guha (webassembly implementation and evaluation, in-browser effect implementations, continuation), Steve Blackburn (virtual machine design, garbage collection), Amal Ahmed (language interop, assembly-level guarantees), Zach Tatlock (browser semantics, mechanical formalization and verification, certified compilers, floating point), and Steve Chong (security, information flow)
Discuss new proposal that introduces types for modules and instances (and text format thereof), as initially discussed in design/#1289
LW: slides on module/instance types Motivation is how do you specify the interface of a wasm module. Either a binary or the host. [presenting slides]
POLL: Move to stage 0?
PH: Most tools deal with just binary and not text format. Would be good to define a binary format for this.
PH: Biggest debate is whether there’s a signifier about whether this should be a module type or an instance type.
FM: Can this be extended to ML Functors?
AR: a wasm module is essentially a functor in the ML sense
FM: Compositionality seems to be missing, having modules that return modules as the value.
AR: what wasm calls a module is what ML would call a functor and what ML calls a structure is what wasm calls an instance
FM: Can you have a module that implements the effect of importing/exporting and does something in between? Right now this is what the instantiator does, but can the module drive that?
AR: it’s a separate thing form this proposal. We’ve talked about it, but doesn’t need to be part of this proposal.
LI: there’s nothing stopping you from calling the JS API to instantiate a module from wasm. Everything is an i32 though.
AR: Yeah, it’s a bit.. You really have to got through JS for everything - there’s no way to express what’s an import/outside outside of that, and we express tham as integer indices - I think what FM is asking if there’s something more direct? Interesting, but one step at a time
PP: What’s going to use this functionality?
LW: Usecase may be that - defining a standard interface for WASI - That’s in one language independent form like the s-expression format in the slide, and can be compiled to a header.
PP: right now clang would not generate anything for this. Until you get to a body you don’t generate anything. Maybe would change for C++ modules.
??: Precursor for dynamically linked libraries
AR: can’t really say how it would work with C++ specifically but it could describe the interface between a provider and a client in general. You could define subtyping on module types so you could tell when a change to a module is backwards compatible with existing clients (e.g. when it’s a subtype). There are a couple open issues in wasm and wasi where we want some IDL for wasm, which pretty much is just the module types.
One was phrased as an IDL, another as a way for a module to to have imports/exports?
PP: what language would use this now?
JG: In C++ or clang, you are able to specify import functions, you can already build that type of interface.
DG1: we could generate this file form C++ code
FM: It’s the linker level that’s going to make the most use of this, is that correct?
DG1: not necessarily. It could be used statically as well. The C++ Frontend would see it too..
PP: Right now, everything that the clang backend - Linker is the one that makes everything visible - the header files are transparent - we don’t really have a way to convert a header - no way to convert it to an interface file. The linker right now does not consume any such files.
DS: In some other systems you can make stub libraries, which are very similar to this idea; just an interface. the linker could use this, these are non-standard things, but there is a precedence to this.
PP: interested in knowing if anyone knows how to use this from other langauges? In C you could do a form of dynamic linking wit this
JG: There’s essentially two cases - building an interface, or using an interface - the interface is defined by the imports/exports - you can strip out all the bits that are not your import/export and that will be the interface - like a post-processing tool
PP: makes sense
POLL: Stage 0 to create a repository
TL: shouldn’t this be a stage 1 poll?
DG not that much difference.
AR: stage 0 is just to create the repo basically.
TL: we just skipped to stage 1 with feature detection
DG: we have this as a proposal for 0: we can just leave it as that
| SF | F | N | A | SA |
|---|---|---|---|---|
| 17 | 6 | 1 | 0 | 0 |
CW: I was asked to plug a workshop going on called “wasm beyond the browser” at UC Berkely on Aug 9. There’s remote participation too. [http://cseweb.ucsd.edu/~dstefan/wasm-beyond-the-browser/]