Re: implementation dependencies (was Re: ES4 work)
On Feb 21, 2008, at 11:40 PM, Michael O'Brien wrote: The reason is we could remove a few road blocks with some design notes. These won't be as complete as the spec but could from the basis of writing some of the spec prose. Ok. Also, the spec can reference the RI (not just SML but, for the standard library, the self-hosted ES4!) in a systematic way. Proposals preceded the RI. The problem here is time. I think doing the spec with the required level of rigour will take much longer than would be ideal to get implementations started. Yes, I've agreed with this loudly recently (no waterfall). Tracking issues is a job for the trac, although there's always room for on-the-side summaries linking to tickets, if you keep editing to keep up with the primary source of truth in the trac. I think the summaries are where the gold is. That is the piece we are missing. We actually have a lot of information, but it is scattered and hard to put together in a coherent manner. In this light the overview and tutorial were more than the sum of their parts from the wiki and trac. I'll start the ball rolling with writing up some notes on Program Units, use unit and unit dependencies. Brendan/Jeff: what format would you like these notes in? You missed this question above. No, I ducked :-). Lars is editor with Jeff assisting and (as always) maintaining the grammar; I would appreciate Graydon's thoughts too. /be ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: implementation dependencies (was Re: ES4 work)
What about the actual content sections? We want the same look and feel over the text -- what perspectives do you need covered in describing a feature. Do you have a sample? Michael Graydon Hoare wrote: Brendan Eich wrote: I'll start the ball rolling with writing up some notes on Program Units, use unit and unit dependencies. Brendan/Jeff: what format would you like these notes in? You missed this question above. No, I ducked :-). Lars is editor with Jeff assisting and (as always) maintaining the grammar; I would appreciate Graydon's thoughts too. *Shrug* I'm not picky. I think Lars has been working more in HTML, and that's what I hope most of the spec-writing will happen in, just because it's real easy to render, edit, version control and such. But plaintext or some flavour of wikitext is also convenient. Word docs less so, though I think they're the final target form ECMA wants. And of course there are our more academic members who feel more at home in LaTeX. Whatever floats your boat. It's relatively easy to interconvert, either way. -Graydon ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: implementation dependencies (was Re: ES4 work)
On Feb 19, 2008, at 6:39 PM, Graydon Hoare wrote: Finally there is a category I left off the above elaboration, mostly because it is under-developed in the RI: control mechanisms. There are dependencies between tail calls, generators and stack inspection, and I can't say I fully understand the dependencies nor the impact they have on the rest of the implementation. This reminds me of something that Maciej already questioned in his initial response to the language overview: if the control inspector is optional, it's either useless on the web because not supported by all major browsers, or else de-facto non-optional: mandatory due to support in one or two top-market-share browsers. Therefore it should not be included as an optional part out of ES4. We already agreed not to make it mandatory for the sake of small-device implementations. I like the control inspector proposal (http://wiki.ecmascript.org/ doku.php?id=proposals:stack_inspection), but Maciej's argument seems decisive to me. Those of us likely to implement it in the near term could work on developing an ad-hoc spec from the proposal, to be considered for inclusion in a later edition. Generators have an implementation plan in the RI based on delimited continuations in SML, and we seem to have reached consensus recently on proper tail calls. To lighten the load and focus on these two high- value control abstractions proposed for ES4, could we think about deferring control inspector? This is discussion fodder, I'm not yet filing a trac ticket. /be ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: implementation dependencies (was Re: ES4 work)
Seems to me we may have some emerging agreement on the following items. Please be kind if I'm overstating the consensus, but I believe the following items start us in the right direction without being too onerous. Triage the existing proposals into those that are current and correct and those that aren't. Publish that list. Bring the out-of-date proposal pages up to date Implementers designers pitch in and write up design notes for proposals. This is then both input to the spec and immediate guidance for implementers. Some doc/comments for the RI Create a common place to store resolutions and clarifications on issues. The mailing list isn't great for this gems get lost in the volume. Perhaps the author for each design note could maintain the document and append questions on the end as clarifications in wiki style. I'll start the ball rolling with writing up some notes on Program Units, use unit and unit dependencies. Brendan/Jeff: what format would you like these notes in? Michael ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: implementation dependencies (was Re: ES4 work)
Comments below: This sounds good, but if we've accepted proposals and need detailed specs, why not write specs? This is not just a matter of wiki namespace (proposal: vs. spec:). Proposals have emphasized precedents, use-cases, and anti-use-cases, and considered alternatives. Discussion uncovered further detail, but still not enough for a spec in all cases. The reason is we could remove a few road blocks with some design notes. These won't be as complete as the spec but could from the basis of writing some of the spec prose. Also, the spec can reference the RI (not just SML but, for the standard library, the self-hosted ES4!) in a systematic way. Proposals preceded the RI. The problem here is time. I think doing the spec with the required level of rigour will take much longer than would be ideal to get implementations started. Suggest we evaluate Lars's forthcoming library spec and see what proposals pages it effectively updates. Agree we should mark those pages somehow as superseded by specs, with links to the specs. Not thrilled about leaving out-of-date proposals around, but there's clearly a conflict between the wiki, which is great for content creation, and the trac and spec, which are better for disposition and finalizable specification. I've seen an early cut of the Library spec. Is an update coming? Again I am leery of reinventing the RI in prose, duplicating its meaning with added bugs and no testability. Better to refer to the RI directly as I think you proposed earlier, or even excerpt it as was planned for the spec. The ES4 excerpts should not need lowering; Graydon's script can be used if people find SML hard to read. Fine to refer to the RI, but I think we're talking notes here. Graydon's emails contain a lot of good notes but are certainly not a spec (yet). I think we just need more of those notes. I would agree that if this can't be done simply and easily, we should just push on as forward momentum will eventually deliver the goods. Time is never a friend if we are slow or meandering. Create a common place to store resolutions and clarifications on issues. The mailing list isn't great for this gems get lost in the volume. Perhaps the author for each design note could maintain the document and append questions on the end as clarifications in wiki style. Tracking issues is a job for the trac, although there's always room for on-the-side summaries linking to tickets, if you keep editing to keep up with the primary source of truth in the trac. I think the summaries are where the gold is. That is the piece we are missing. We actually have a lot of information, but it is scattered and hard to put together in a coherent manner. I'll start the ball rolling with writing up some notes on Program Units, use unit and unit dependencies. Brendan/Jeff: what format would you like these notes in? You missed this question above. Cheers Michael ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 work
Graydon, Thanks -- that helps to understand the status. You are in a somewhat unique position having implemented more than any other. Given Jeff's roadmap outline and the goal of weighing the features against implementation experience -- which of the features that you have implemented do you feel were difficult, costly or problematic? In our implementation (Ejscript), we have implemented (with bugs): - classes - namespaces, including use pragmas - block scope - packages - units - pragmas - let, const, let-const - type expressions / definitions / annotations - runtime type checks (standard mode) - destructuring assignment - hashcode - meta objects - strict mode (incomplete checking) - type parameters - numbers decimal - getters setters Namespaces was a much bigger and more intrusive change that I first anticipated. Difficult to get it to perform well, but we're still working on it. However, once byte-code is generated for bound code, there is no cost. Similarly, block scope added considerable complexity. Program units were fairly straight forward as is strict mode and pragmas. Structural types and type checking is next on our high priority list. Michael Graydon Hoare wrote: Michael O'Brien wrote: Could Graydon give a snapshot of what is not implemented in the RI in terms of the proposals / features? I know the trac database lists all, but a punch list of the high priority deficits would be helpful. Sure. I can describe the state of most issues as named by the proposals page, I think. Some of the proposals have sort of no-longer-sensible names so I'm going to use the proposals page as a rough guide and name the things that have seemed, in my work, to be separate features of the RI. Implemented, may have bugs: - classes and interfaces - namespaces - pragmas - let, const, let-const - iterators - enumerability control - type expressions / definitions / annotations - runtime type checks (standard mode) - nullability - destructuring assignment - slice syntax - hashcode - catchalls - map vector - date time improvements - meta objects - static generics - string trim - typeof - globals - expression closures - name objects - type operators (is / to / cast / wrap) Implemented and partly working, but still in flux / work to do: - inheritance checking - strict mode - type parameters - structural types - numbers decimal - getters setters (structural part is incomplete) - packages Partially implemented / not yet working: - program units - generic function - updates to unicode - updates to regexps Unimplemented: - generators - tail calls - triple quotes - stack inspection - reformed with - resurrected eval (eval exists but may be wrong) - help for the argument object - this function / this generator In my mind the high priority deficits where I actually know what to do are: - extending strict mode - extending the part of the definer that checks inheritance The remaining issues on my list all involve some spec/discussion work (units and packages, type parameters, structural typechecks, tail calls, reformed rules for with/this/eval/arguments) -Graydon ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: implementation dependencies (was Re: ES4 work)
Comments below: Going further, I have mentally considered the language as providing 3 big categories of enhancement: fixtures, types, and namespaces. I think that within -- and possibly between -- these groups there are dependencies. For example, we can consider these levels of type-implementation: TY-VAL: a runtime representation of types exists, and values have a pointer to their type TY-PROP: properties can be annotated with types, and a dynamic check is made when an assignment is made TY-DEF: type-aliases (type T = ...) can be defined TY-STRUCT: the full structural type grammar exists (object types, array types, function types) TY-NULL: the nullability extension to the type grammar exists TY-NOMINAL: class and interface types exist, with a hard-coded subtype lattice TY-PARAM: the parametric type system exists TY-LIKE: the 'like' types exist TY-STRICT: approximate static checking of types TY-REFLECT: meta-objects exist and can be acquired with typeof This is a partial dependency list. You need at least TY-VAL to do TY-PROP, but it's probably possible to implement any combination of the remainder once you're at TY-PROP. You could also stop *at* TY-PROP, only permitting users to denote the ES3 types (prims and objs). Though IMO this would be silly. We began and have a fairly complete TY_VAL and TY_PROP. Next we did TY_NOMINAL and TY_REFLECT. We are missing DEF, STRUCT, NULL, PARAM and LIKE. We have partial STRICT. We can also consider levels of namespace-implementation: NS-VAL: a runtime type namespace exists, and has some nonempty population NS-PROP: every property has a namespace and namespace references can be used in reference expressions like obj.ns::prop and ns::lexref NS-USE: the use namespace and use default namespace pragmas automatically qualify definitions or references NS-DEF: namespace declarations are accepted and new namespaces can be defined through them, either anonymous or with strings NS-CLS: classes (and interfaces?) define their own namespaces for conventional OO visibility control NS-PKG: the package construct exists for automatically defining namespaces Similarly, this list is more linear at the top than the bottom: NS-PROP and NS-USE require NS-VAL, though one could stop there with (perhaps) a fixed population of namespaces. The remaining 3 are mostly orthogonal: you could for example stop implementing with NS-DEF and ignore classes and packages, and still have a useful system. Or do NS-CLS alone and ignore NS-DEF, using namespaces only to model class-visibility issues. I think this is very much an all or nothing. It is hard to separate out these from each other. We started with NS_DEF, NS_VAL and NS_PROP. NS_USE was easy NS_USE is pretty easy once you have NS_VAL and NS_PROP. NS_PKG is essential if you are going to handle package qualified variables and avoid name collisions. So I'd imagine it would be hard to have a cohesive whole without doing all these items. All the type and namespace issues depend, however, on fixtures. We are some ways towards proving that fixtures-in-absence-of-namespaces are equivalent to the dontdelete property attribute (see ticket #233, http://bugs.ecmascript.org/ticket/233) but if you have namespaces there appears to be a requirement to be modeling fixtures, to run the multiname algorithm properly. Fixtures are sort of super-dontdelete properties -- those that can safely be early bound, in addition to not being deletable -- and it's hard to make much use of the namespace or type systems without them. Agree. We had fixtures first and retrofitted namespace (which I would not recommend). Namespaces are so foundational, you need to design them in at the start. Otherwise, there is a lot of rework. Re-encoding the ES3 primitives as classes, and the new classes like map, vector and the meta objects, all require a fair amount of the TY and NS work: at least TY-NOMINAL, TY-PARAM and NS-CLS (I think). Looking at the builtins, I can't imagine how you could do them without namespaces. They are a vital solution to various name lookup and collision problems. Finally there is a category I left off the above elaboration, mostly because it is under-developed in the RI: control mechanisms. There are dependencies between tail calls, generators and stack inspection, and I can't say I fully understand the dependencies nor the impact they have on the rest of the implementation. There are a whole raft of implementation toughies that will vary a bit from implementation to implementation. We have spent a lot of time trying to get ES4 to be small and fast. But there is a long, long way to go. Michael -Graydon ___
Re: ES4 work
Michael O'Brien wrote: Graydon, Thanks -- that helps to understand the status. You are in a somewhat unique position having implemented more than any other. Given Jeff's roadmap outline and the goal of weighing the features against implementation experience -- which of the features that you have implemented do you feel were difficult, costly or problematic? Actually, despite my having acquired some sort of RI maintainer moniker, I did not write the majority of it. By volume I think the largest parts have come from Adobe and Opera people. The builtins and frontend each weigh about as much as the remainder (machine model, evaluator, type system). My sense was that I had the most difficulty with the type and scope rules, but not so much because they were problematic as much as that we kept changing the rules. Also that even a minor bug in the rules typically produces a non-booting system, as the builtins stop working. There was also (and continues to be) considerable subtlety in wiring up convincing builtin classes that behave the same as the ES3 primitives and ad-hoc host objects. I can certainly imagine your experience though: if one doesn't have namespaces or the proper block scope forms in the system to start with, retrofitting them will likely be annoying. Likewise types. But the RI had some portion of these from the get-go (we retrofitted a unified scope-initialization primitive into it once the rules became clear half way in, and this was costly). Structural types will probably pose a bit of pain because they require a type-term normalizer with some subtle parts. There is an example in type.sml but it's certainly not the sort that illuminates the subtle points! It should be cleaned up during spec'ing. That normalizer also gets significantly weirder once you introduce type parameters (it turns into a sort of partial evaluator). -Graydon ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
RE: ES4 work
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael O'Brien Sent: 17. februar 2008 02:12 To: Jeff Dyer Cc: es4-discuss Discuss; TC39 Subject: Re: ES4 work Jeff, Responses below: Jeff Dyer wrote: Many of those proposals on the Wiki are dated and much water has gone under the bridge on these proposals since they were first made. Many conversations have been had with sometimes subtle and sometimes not so subtle changes to the meaning of those proposals. This presents a real problem for implementers in understanding exactly what has been proposed and what is the meaning of the proposals. For those who were present in those conversations and meetings may have it all committed to memory, but those who have not present will certainly struggle to gain a clear and exact understanding, as I do. You are correct in saying that the proposals don't all stand on their own. This is the problem we intend to solve by requiring production implementations to support complete and accurate feature specifications. Each proposal carries with it a significant context, more or less captured in meeting notes, trac tickets, the RI, and various people's heads. The implementation focus will have two important effects: 1/force the translation of proposals (by those with the necessary context to do so) into implementations and feature specs that will stand on their own; 2/give everyone else specific interpretations of those proposals to respond to. Still a bit of a catch 22 for implementers. I wonder. Consider a complicated feature like classes. The basis document is the ActionScript 3 specification; it has been augmented by several proposals (for meta-level hooks and settings, for example), and classes are implemented in the RI. There are trac tickets too. What an implementation must do is to collect all these threads and provide a coherent implementation/specification pair, and that requires real work, but the groundwork has been laid by the background materials. In my opinion, an implementer who wants to take on classes will not do this in isolation, but will probably team up with at least one other implementer, and will have the attention of everyone who has been involved in the discussion in the working group. What would help a great deal are unit tests and sample code for how the features actually work. We've found that reading the builtins has helped in many cases. That's good, and it makes sense, since the builtins probably constitute the largest corpus of working ES4 code at this time. Test cases would indeed help Is there a plan to develop unit tests cases that the implementations can use? Adobe is dedicating some people to this task, but in my opinion it will be necessary for basic functional tests to come from the implementers who take care of a particular feature. So my question is what are the agreed set of proposals and where are they adequately documented? The agreed set of proposals are the ones posted on http://wiki.ecmascript.org. Adequate documentation is what we intend to produce, along with the all important agreement about what can and should be implemented in our products. Admittedly we have a bit of a bootstrapping problem here: we need to implement to know what we have agreed to, and we need to understand what we agreed to to implement. But with the right people working together I am confident that this cycle can be broken. I've found the paper that Lars and others worked on to be very helpful, but it was targeted at a broad audience. We find that we often drill down questions that are not easily answered. For example: what is the exact scope for function default parameter expressions, constructor initializers etc. These were answered via QA, but not captured in a systematic way for others with the same questions. We need a way to capture clarifications and QA. Could we take a copy of Lars's paper and perhaps extend as unanswered questions are raised and answered. Then that Paper would become an excellent bridging tool until the spec is written and available. The specifications written for specific pieces of the language are that way to capture clarifications and QA, I think. In some sense the RI captures them too, but does not capture the broader discussion about what was not done. Prose does that better. I would be happy to re-read and come up with questions that we have that are still unanswered or unclear. A related question that exacerbates this problem is what has become
Re: ES4 work
Hi Michael, Thanks for your comments and questions. I¹ll try to address them here, and hopefully you¹ll be able to join us on the next Tuesday phone call so we can further flush out the issues. ³1. What actually are the proposals?² ³Many of those proposals on the Wiki are dated and much water has gone under the bridge on these proposals since they were first made. Many conversations have been had with sometimes subtle and sometimes not so subtle changes to the meaning of those proposals. This presents a real problem for implementers in understanding exactly what has been proposed and what is the meaning of the proposals. For those who were present in those conversations and meetings may have it all committed to memory, but those who have not present will certainly struggle to gain a clear and exact understanding, as I do.² You are correct in saying that the proposals don¹t all stand on their own. This is the problem we intend to solve by requiring production implementations to support complete and accurate feature specifications. Each proposal carries with it a significant context, more or less captured in meeting notes, trac tickets, the RI, and various people¹s heads. The implementation focus will have two important effects: 1/force the translation of proposals (by those with the necessary context to do so) into implementations and feature specs that will stand on their own; 2/give everyone else specific interpretations of those proposals to respond to. ³So my question is what are the agreed set of proposals and where are they adequately documented?² The agreed set of proposals are the ones posted on http://wiki.ecmascript.org. Adequate documentation is what we intend to produce, along with the all important agreement about what can and should be implemented in our products. Admittedly we have a bit of a bootstrapping problem here: we need to implement to know what we have agreed to, and we need to understand what we agreed to to implement. But with the right people working together I am confident that this cycle can be broken. ³A related question that exacerbates this problem is what has become of the discussion to trim / streamline some of the feature set. As implementers, we don't want to spend time implementing features that are not likely to be in the final spec.² An important side effect of an implementation focus is the prioritization of features. There is a core set of well understood features that I believe we need to include for the language to support itself (e.g. the built-ins). On the other hand most of us have a list of features we could live without, or believe are not sufficiently baked to qualify for standardization. Those lists should be shared and guide our individual investments in implementation, but I don¹t think they should take priority over real world experience implementing and using the language. And I absolutely don¹t want to spend my time debating the content of those lists until we have implementation and user experience to ground that debate. A huge amount of time and (inspired) effort has gone into creating the current set of proposals. We need to be careful to protect that investment by following a process that allows viable features to take root and others to naturally wither and die. As early implementers we necessarily run the risk of implementing features that don¹t make it into the standard. On the other hand, we learn before others what works and what doesn¹t. Again the point of this exercise is to leverage that experience to get the language as close to right as possible. ³2. The RI is a key implementation too. In your work flow, the RI seems to lag the implementations and you say it has a role in prototyping features. But it has been filling a crucial role in clarifying what the proposal was really meant to do. This goes beyond prototyping. I regard the RI as the first implementation and the last. The first, in the sense that it should define how the features are meant to function and guide implementers and prevent many blind alleys. The last in the sense, that it defines the spec. I'd like to stress that it must continue to lead in implementing all key features.² Admittedly I was doing a little hand waving here. Clearly the RI has given us early insight into the language design, forced issues to the surface sooner rather than later, and given us a model to play with. And in terms of feature scope, the RI is fairly complete (thanks mostly to Graydon). The point of the workflow is to show when key milestones are reached. In this end game plan, here really isn¹t a clear and useful milestone associated with the initial implementation in the RI. We could define one but that might just add unnecessary overhead to the process. I see the current RI as a part of that bundle of materials we call Proposals. ²Your timeline below does not indicate the kind of implementation readiness you need to make this work flow actually work. Can you detail what kind
Re: ES4 work
Jeff, Responses below: Jeff Dyer wrote: Re: ES4 work Many of those proposals on the Wiki are dated and much water has gone under the bridge on these proposals since they were first made. Many conversations have been had with sometimes subtle and sometimes not so subtle changes to the meaning of those proposals. This presents a real problem for implementers in understanding exactly what has been proposed and what is the meaning of the proposals. For those who were present in those conversations and meetings may have it all committed to memory, but those who have not present will certainly struggle to gain a clear and exact understanding, as I do. You are correct in saying that the proposals dont all stand on their own. This is the problem we intend to solve by requiring production implementations to support complete and accurate feature specifications. Each proposal carries with it a significant context, more or less captured in meeting notes, trac tickets, the RI, and various peoples heads. The implementation focus will have two important effects: 1/force the translation of proposals (by those with the necessary context to do so) into implementations and feature specs that will stand on their own; 2/give everyone else specific interpretations of those proposals to respond to. Still a bit of a catch 22 for implementers. What would help a great deal are unit tests and sample code for how the features actually work. We've found that reading the builtins has helped in many cases. Is there a plan to develop unit tests cases that the implementations can use? So my question is what are the agreed set of proposals and where are they adequately documented? The agreed set of proposals are the ones posted on http://wiki.ecmascript.org. Adequate documentation is what we intend to produce, along with the all important agreement about what can and should be implemented in our products. Admittedly we have a bit of a bootstrapping problem here: we need to implement to know what we have agreed to, and we need to understand what we agreed to to implement. But with the right people working together I am confident that this cycle can be broken. I've found the paper that Lars and others worked on to be very helpful, but it was targeted at a broad audience. We find that we often drill down questions that are not easily answered. For example: what is the exact scope for function default parameter expressions, constructor initializers etc. These were answered via QA, but not captured in a systematic way for others with the same questions. We need a way to capture clarifications and QA. Could we take a copy of Lars's paper and perhaps extend as unanswered questions are raised and answered. Then that Paper would become an excellent bridging tool until the spec is written and available. I would be happy to re-read and come up with questions that we have that are still unanswered or unclear. A related question that exacerbates this problem is what has become of the discussion to trim / streamline some of the feature set. As implementers, we don't want to spend time implementing features that are not likely to be in the final spec. An important side effect of an implementation focus is the prioritization of features. There is a core set of well understood features that I believe we need to include for the language to support itself (e.g. the built-ins). On the other hand most of us have a list of features we could live without, or believe are not sufficiently baked to qualify for standardization. Those lists should be shared and guide our individual investments in implementation, but I dont think they should take priority over real world experience implementing and using the language. And I absolutely dont want to spend my time debating the content of those lists until we have implementation and user experience to ground that debate. Agree that those lists are not worth debating, but definitely worth sharing. It would help sway some of our priority discussions. A huge amount of time and (inspired) effort has gone into creating the current set of proposals. We need to be careful to protect that investment by following a process that allows viable features to take root and others to naturally wither and die. Agree. I'm very thankful for all the efforts that the group have invested in the language. It is easy to come late to the party and not understand the wisdom that has been expended in many conversations and prior debates. As early implementers we necessarily run the risk of implementing features that dont make it into the standard. On the other hand, we learn before others what works and what doesnt. Again the point of this exercise is to leverage that experience to get the language as close to right as possible. Understand. We are happy with this risk. In fact, most implementations will innovate at the edges. This is the way we gain real experience for future drafts of the language
ES4 work
Hi, We have entered a new phase in the development of the ES4 standard. Since September we have had a fixed set of proposals to consider individually and as a whole. The final step is to translate those proposals into production implementations and to document the language that results to become the next ES standard. What follows is a high level description of the process that we (Adobe and Mozilla) feel should be followed to get from Proposals to a high quality, finished specification. We should discuss this at our ES4-WG phone call this Tuesday (Feb-19). Advanced comments welcomed. WORKFLOW The basic workflow: Proposal -- Implementation -- Feature spec -- Feature review -- ES4-RI -- ES4 spec -- Proposal - see http://wiki.ecmascript.org/doku.php?id=proposals:proposals. These proposals are the pool of possible feature proposals. Only exceptional circumstances will warrant a feature not covered by an accepted proposal to be considered. Implementation - interested implementers collaborate on the implementation of a feature described by the proposals. This exercise should end with one or more implementations of the feature to provide feedback on usability and implementation complexity. Feature spec - one of the participants from the implementation team writes up a description of the feature based on that implementation. Feature specs are complete and accurate descriptions of individual features to be added to the language. They are supported by production implementation, test cases and implementer commitment to release the feature. Feature review - ES4-WG reviews the feature spec and implementation and when satisfied accepts the spec to be included in the ES4 spec. ES4-RI - once accepted, the RI is checked for compatibility with the production implementation and readability. Although the RI is used as a kind of prototype of the proposals, its primary purpose is aide in understanding and exposition of the language. This step involves preparing parts of the RI for inclusion in the spec. ES4 spec - and finally, the ES4 draft is updated to include the accepted feature and reviewed first by ES4-WG and then TC39. IMPLEMENTATION TEAMS The implementation teams will be ad hoc collaborations between two or more implementers. Ideally, at least one of those implementers is an Ecma member so that the feature has representation throughout the standardization process. ES4-WG AND TC39 MEETINGS The ES4-WG meetings should focus on the review of feature specs and ES4 spec drafts. Two weeks before each TC39 meeting a draft of the ES4 spec will be distributed for review by the TC39 members. SCHEDULE In order to be approved at the December 2008 GA, a final draft of the ES4 spec must be ready for review at the Sep TC39 meeting. This is clearly an aggressive schedule, but one that is achievable given that high quality feature specs are produced by several feature teams in parallel. We envision at least two teams working in parallel on AS3-like features and JS1.7-like features. Here is a very high-level schedule of deliverables to TC39 Mar - draft 1 - ES3 spec based on the ES4-RI - Library spec May - draft 2 - Core language mostly spec-ed Jul - draft 3 - Spec complete Sep - draft 4 - Final review Oct - final draft - Send to CC for approval ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 work
Jeff, Thanks for outlining the process to go forward. Overall I like having real implementations prove the value and feasibility of features and proposals before they are poured in concrete. But I see 2 2 obstacles that I outline below: 1. What actually are the proposals? Many of those proposals on the Wiki are dated and much water has gone under the bridge on these proposals since they were first made. Many conversations have been had with sometimes subtle and sometimes not so subtle changes to the meaning of those proposals. This presents a real problem for implementers in understanding exactly what has been proposed and what is the meaning of the proposals. For those who were present in those conversations and meetings may have it all committed to memory, but those who have not present will certainly struggle to gain a clear and exact understanding, as I do. I've been using the RI, Lars's paper and emailed questions to flesh out my understanding of the proposals -- but my understanding is often incomplete or inaccurate. So my question is what are the agreed set of proposals and where are they adequately documented? A related question that exacerbates this problem is what has become of the discussion to trim / streamline some of the feature set. As implementers, we don't want to spend time implementing features that are not likely to be in the final spec. 2. The RI is a key implementation too. In your work flow, the RI seems to lag the implementations and you say it has a role in prototyping features. But it has been filling a crucial role in clarifying what the proposal was really meant to do. This goes beyond prototyping. I regard the RI as the first implementation and the last. The first, in the sense that it should define how the features are meant to function and guide implementers and prevent many blind alleys. The last in the sense, that it defines the spec. I'd like to stress that it must continue to lead in implementing all key features. Your timeline below does not indicate the kind of implementation readiness you need to make this work flow actually work. Can you detail what kind of implementation feedback you need? Lastly, please don't interpret the above 2 issues as negative feedback. I think this is a good and normal process for defining a spec. We need to have real-world experience using these features to prevent painful errors going forward. thanks Michael O'Brien Mbedthis Software Jeff Dyer wrote: Hi, We have entered a new phase in the development of the ES4 standard. Since September we have had a fixed set of proposals to consider individually and as a whole. The final step is to translate those proposals into production implementations and to document the language that results to become the next ES standard. What follows is a high level description of the process that we (Adobe and Mozilla) feel should be followed to get from Proposals to a high quality, finished specification. We should discuss this at our ES4-WG phone call this Tuesday (Feb-19). Advanced comments welcomed. WORKFLOW The basic workflow: Proposal -- Implementation -- Feature spec -- Feature review -- ES4-RI -- ES4 spec -- Proposal - see http://wiki.ecmascript.org/doku.php?id=proposals:proposals. These proposals are the pool of possible feature proposals. Only exceptional circumstances will warrant a feature not covered by an accepted proposal to be considered. Implementation - interested implementers collaborate on the implementation of a feature described by the proposals. This exercise should end with one or more implementations of the feature to provide feedback on usability and implementation complexity. Feature spec - one of the participants from the implementation team writes up a description of the feature based on that implementation. Feature specs are complete and accurate descriptions of individual features to be added to the language. They are supported by production implementation, test cases and implementer commitment to release the feature. Feature review - ES4-WG reviews the feature spec and implementation and when satisfied accepts the spec to be included in the ES4 spec. ES4-RI - once accepted, the RI is checked for compatibility with the production implementation and readability. Although the RI is used as a kind of prototype of the proposals, its primary purpose is aide in understanding and exposition of the language. This step involves preparing parts of the RI for inclusion in the spec. ES4 spec - and finally, the ES4 draft is updated to include the accepted feature and reviewed first by ES4-WG and then TC39. IMPLEMENTATION TEAMS The implementation teams will be ad hoc collaborations between two or more implementers. Ideally, at least one of those implementers is an Ecma member so that the feature has representation throughout the standardization process. ES4-WG AND TC39 MEETINGS The ES4-WG
