Modules spec procedure suggestion (Re: Jan 31 TC39 Meeting Notes)
On Thu, Feb 7, 2013 at 1:00 PM, Claus Reinke <claus.reinke at talk21.com> wrote:
There are some existing ES.next modules shims/transpilers that could be used as a starting point.
Here is an experiment I did with a JS module syntax that allowed for a static compile time hooks for things like macros, but still allowed JS that needed to exist both in pre-ES.next and ES.next to opt into modules (think base libraries like jQuery, underscore, backbone).
It has some tests, and the modus.js file runs in ES5 browsers.
Since the modules desugar to runtime APIs after the compile time pass for macros, it means not getting the lower level variable bindings that the ES module format is targeting. This means it has similar cycle dependency support as AMD -- it can be done, but may not be as nice as ES module variable binding, and has some restrictions.
The API and syntax was just provisional, just something chosen to wire things together, and it is not a fully fleshed out system. Also, it was not done to advocate macros in particular. Macros were used to demonstrate how a static, "compile time" feature could be supported in a system that desugared to runtime API calls, and it helped that sweetjs was available for that heavier lifting.
It may be useful for others to look at as a way to prototype any official ES spec approach, even if it does not give full fidelity. In particular, the use of the sweetjs reader to do a first pass transform of the module syntax.
James
There has been a great deal of pressure from users wanting details about whether the modules spec will cover their use cases, from module library authors wanting to determine whether their most important features will be covered (so that they can retire their systems), and -more recently- from transpiler authors and users needing to know what spec to target (existing implementations being invalidated by late spec changes doesn't help, either).
It looks like this has finally "blown up" at the last meeting (excerpts included below). The main concern seems not to be with specific features but with lack of confidence and missing details.
One way to restore confidence would be to go the "executable spec" route: implement the modules spec in JS, as a transpiler.
That would force the spec to be described in implementable detail (no "to determined later"), would allow use cases to be written as tests (no "I can't tell whether the spec covers this"), and would make concrete discussions possible (no "this doesn't feel right" vs "don't worry, it'll all work out in the end") - all the usual advantages of executable specifications
There are some existing ES.next modules shims/transpilers that could be used as a starting point.
Just a suggestion, Claus
There has been a great deal of pressure from users wanting details about whether the modules spec will cover their use cases, from module library authors wanting to determine whether their most important features will be covered (so that they can retire their systems), and -more recently- from transpiler authors and users needing to know what spec to target (existing implementations being invalidated by late spec changes doesn't help, either). It looks like this has finally "blown up" at the last meeting (excerpts included below). The main concern seems not to be with specific features but with lack of confidence and missing details. One way to restore confidence would be to go the "executable spec" route: implement the modules spec in JS, as a transpiler. That would force the spec to be described in implementable detail (no "to determined later"), would allow use cases to be written as tests (no "I can't tell whether the spec covers this"), and would make concrete discussions possible (no "this doesn't feel right" vs "don't worry, it'll all work out in the end") - all the usual advantages of executable specifications There are some existing ES.next modules shims/transpilers that could be used as a starting point. Just a suggestion, Claus > LH: One of the things the module system needs, to move forward, there > should be 5-10 real world scenarios. Each scenario needs to be met and > _recorded_, each time a change is made, it needs to be applied to each > scenario to ensure that we're covering the needs. >.. > BE: This is not design by committee, we _really_ need user testing. >.. > LH: We need to drive this through with concrete examples and use those > steer the development here. I don't think we're going to get anywhere here > today. > .. > LH: As much as it would be great to deliver this, it's simply not ready and > not nearly developed or concrete enough to continue forward with. We'd need > a year to user test to get the best results from the feature. Need to > understand and meet the needs. >.. > STH: There is a great deal of completed work for this and with valuable > feedback, we can still deliver. It's not fair to say "We're providing you > with feedback, therefore you're not done". > > BE: Yes, we need algorithms in the spec and user testing in time. > > EA: Modules are the most important feature that we have to ship, but I > agree with Doug that it might not be in time. > > BE: One option is to move it to ES7 >.. > STH: I believe strongly that the state of the module system is being > mis-perceived. > ... > EA: From implementation, modules is the highest priority, but there is > nothing to implement. > > AWB: And much of the spec will rely on modules. > > MM: Comparisons of the lexical scoped modules and the new string name > modules > > BE: ...Recalls the argument from 3 years ago. Notes that IIFE is NOT what > `module {}` is and cannot be compared. > > DC: I've spent years promoting this, but I can't see how it will make it. > > AWB: We should aim for a "maximally minimal modules" proposal, that we can > then move forward with to be successful. > > WH: I like modules but also share Doug's skepticism about them being ready > for ES6 > > ARB: I've been working on implementing modules for a year now and the > changes you made in November invalidated most of that work, and they were > not changes that I could agree with. > > STH: To Clarify, we should not do a design along these lines AND you're > concerned about the schedule. > > ARB/AWB: Don't want to go back to ground zero. > > LH: Start with a more robust design exercise, instead of trying to patch. > > YK: To address the notion that the need has eroded, the systems that have > been developed have actually put us in a worse position. > > EA: Can we get champions of an alternate proposal? Andreas? > > AWB: If we're going to defer or decouple modules from ES6, we need to know > sooner, by the next meeting. > > STH: I believe strongly that the state of the module system is being > mis-perceived. > > EA: I'm really confused by the current system and I feel like i used to > understand the old module proposal well. > > ARB: Same here. > > LH: I don't think the current system is grounded or addresses the real > problems that it needs to address. > ...What we need to accomplish is much deeper. > ...Prior art and experience dictates how the experience will be received > and this doesn't seem to come up. > > YK: I see modules as largely "desugaring" to two things that can be done > with defining and loading in AMD, YUI etc. > > LH: I'm not seeing all of the needs being met. My intuition is to say "this > is a sugar for AMD", I think that could be a solid guiding principle. > > YK: I agree that it's easier to see a path forward if it's largely the same > thing as something that is already in use. > > STH: re: possibly maximally minimal? There are too many details and > requirements that are closer to surface, syntactically. It's harder to > jettison the complicated parts to reduce the work, but also gives me > confidence that the fundamental design is not changing as much as those in > the room may belief. > ...It aligned the programming model with the semantics of the Loader > ...Believe it would be a big mistake not to do modules in ES6. > ...Problematic that we're having this discussion without Dave present. > > RW: We should break and table this until Dave can be present. > > LH/DC/STH: Agree. > > AWB: Concerned that we're on a path that won't include modules. If we're > going to ship within a year of our target, modules won't make it. > > STH: If we characterize it that way, then not many features are ready. > > AWB: Agree. > > RW: We should table this until the next meeting, where we are scheduled to > actually discuss which features move forward and which don't. Additionally, > Dave will be present. > > STH: Of course over the next two months, Dave and I will be working with > Allen to move modules into the spec. > > EA: That could be the best thing. > > RW: Likely to restore confidence if this can be achieved. > > LH: Not convinced we have a design that is ready for the spec. > > ...Seeing this in spec may reify the unknown parts. > > > YK: If we don't have modules in ES6, certain parts will have to be respec'ed > > AWB: I also believe a maximally minimal specification that can be used > internally could happen.