ES4 work

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

ES4 work

Jeff Dyer
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
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ES4 work

Michael O'Brien-4
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 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
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss

  

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ES4 work

Jeff Dyer
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 of implementation feedback you need?”

Two questions come to mind:

1 – do you understand the feature well enough to write a detailed specification of it?
2 – are you willing to ship it as is (modulo bug fixes and performance tuning)?

>”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, no offense taken. On the contrary, I see the advanced ES4 implementation work you have done as a great asset that we need to leverage. The process outlined here can be used by those with shared values and vision to produce a strong specification that defines the language of multiple implementations. It needs further refinement, but mostly it just needs to be done.

Jd


On 2/15/08 11:20 PM, Michael O'Brien wrote:

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 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
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss

  



_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ES4 work

Michael O'Brien-4
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 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.

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 Q&A, but not captured in a systematic way for others with the same questions.

We need a way to capture clarifications and Q&A. 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 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.
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 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. 
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.

> “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.
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.

>”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?”

Two questions come to mind:

1 – do you understand the feature well enough to write a detailed specification of it?
2 – are you willing to ship it as is (modulo bug fixes and performance tuning)?
For #2, we are quite happy to risk shipping features prior to standardization and we will do our very best to adapt, change and track the standard. We are pretty up front with users on this front.

Regarding #1, I may not possess the skill to write specifications. My skills are more as an implementer than a language designer and even less as a writer. I find that I pale when compared to other more leading lights in this regard.

>”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, no offense taken. On the contrary, I see the advanced ES4 implementation work you have done as a great asset that we need to leverage. The process outlined here can be used by those with shared values and vision to produce a strong specification that defines the language of multiple implementations. It needs further refinement, but mostly it just needs to be done.
Your welcome. We are looking forward to releasing our first snapshot soon.


Michael

Jd


On 2/15/08 11:20 PM, Michael O'Brien wrote:

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 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
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss

  



_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

RE: ES4 work

Lars Hansen-3
 


From: [hidden email] [mailto:[hidden email]] 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 Q&A, but not captured in a systematic way for others with the same questions.

We need a way to capture clarifications and Q&A. 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 Q&A, 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 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.
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 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. 
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.

> “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.
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.

>”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?”

Two questions come to mind:

1 – do you understand the feature well enough to write a detailed specification of it?
2 – are you willing to ship it as is (modulo bug fixes and performance tuning)?
For #2, we are quite happy to risk shipping features prior to standardization and we will do our very best to adapt, change and track the standard. We are pretty up front with users on this front.

Regarding #1, I may not possess the skill to write specifications. My skills are more as an implementer than a language designer and even less as a writer. I find that I pale when compared to other more leading lights in this regard. 
 
Even so, the ability to attack a feature and ask questions about how it should behave and find answers to those questions comes so close to being a spec that it's probably good enough to be useful.  The editors (myself and Jeff at this point) will still have to clean it up to incorporate it into the language spec; the original author will need to participate in that iterative process but will presumably not need to spend time on cleaning up the writing.
 
--lars 

>”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, no offense taken. On the contrary, I see the advanced ES4 implementation work you have done as a great asset that we need to leverage. The process outlined here can be used by those with shared values and vision to produce a strong specification that defines the language of multiple implementations. It needs further refinement, but mostly it just needs to be done.
Your welcome. We are looking forward to releasing our first snapshot soon.


Michael

Jd


On 2/15/08 11:20 PM, Michael O'Brien wrote:

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 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
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss

  



_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ES4 work

Graydon Hoare-3
In reply to this post by Michael O'Brien-4
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
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

implementation dependencies (was Re: ES4 work)

Graydon Hoare-3
In reply to this post by Jeff Dyer
Jeff Dyer wrote:

> The basic workflow:
>
>   Proposal -->
>      Implementation -->
>         Feature spec -->
>            Feature review -->
>               ES4-RI -->
>                  ES4 spec -->
>

One thing that springs to mind when looking at this is that the
proposals -- that is, really, the "features" to be implemented -- have
implementation dependencies that need to be reflected in any work plan.

I pointed this out in the phone meeting today and was asked to outline
some of the implementation dependencies I've noted while working on the RI.

I think a certain number of features are mostly-independent of all
others, so they can be cleared off first: enhancements to unicode and
regexps, slice syntax, string.prototype.trim, the global object, triple
quotes, line terminator normalization, improvements to Date, the set of
"pure bug fixes" in ES3, expression closures, let-binding, fixes to the
arguments object, control of enumerability, destructuring assignment.
These are all essentially stand-alone and several have already shipped
as vendor extensions to ES3.

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 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.

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.

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).

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.

-Graydon

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ES4 work

Dave Herman-2
In reply to this post by Lars Hansen-3
> How about hosting a set of unit tests at www.ecmascript.org?

In a sense, we already do; our unit tests are included in the source
download. But it could be a good idea to make the tests independently
available on the web site. We should probably make it clear that these
don't carry any special or official weight of "conformance", however --
they'd just be provided as a convenience to implementers.

Dave
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ES4 work

Michael O'Brien-4
In reply to this post by Graydon Hoare-3
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
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: implementation dependencies (was Re: ES4 work)

Michael O'Brien-4
In reply to this post by Graydon Hoare-3
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
>
> _______________________________________________
> Es4-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es4-discuss
>
>  
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ES4 work

Graydon Hoare-3
In reply to this post by Michael O'Brien-4
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
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: implementation dependencies (was Re: ES4 work)

Brendan Eich-2
In reply to this post by Graydon Hoare-3
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
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: implementation dependencies (was Re: ES4 work)

Michael O'Brien-4
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
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: implementation dependencies (was Re: ES4 work)

Brendan Eich-2
On Feb 21, 2008, at 11:07 PM, Michael O'Brien wrote:

> 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.

Agreed.

> Bring the out-of-date proposal pages up to date

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.

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.

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.

> 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

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.

> 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'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?


Graydon and Lars should weigh in too.

/be
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: implementation dependencies (was Re: ES4 work)

Michael O'Brien-4
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
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: implementation dependencies (was Re: ES4 work)

Brendan Eich-2
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
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: implementation dependencies (was Re: ES4 work)

Nathan de Vries
In reply to this post by Michael O'Brien-4
On Thu, 2008-02-21 at 23:07 -0800, Michael O'Brien wrote:
> Triage the existing proposals into those that are current and correct
> and those that aren't. Publish that list.

All current proposals are marked as "accepted :)", but perhaps there
should be more shades of grey?

I've made the assumption that those who have higher contribution
percentages to proposal pages are probably the best people to ask about
the current state of said proposals. As such, I've generated a list of
proposals and user/percentage contributions which might be useful in
pinpointing those who have the necessary context to bring the pages up
to speed (see attached).

It would be naïve to think that all the contributors to the proposals
are going to be willing to trudge through the required thoughts, list
discussions, tickets & RI to update the pages, but ideally they could
point someone else in the right direction, or perhaps make sure they're
kept on the right track.


Cheers,

--
Nathan de Vries

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss

proposals.txt (7K) Download Attachment
smime.p7s (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: implementation dependencies (was Re: ES4 work)

Graydon Hoare-3
In reply to this post by Brendan Eich-2
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
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

How to unsubscribe from list?

Eugen.Konkov
Question in subject
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

RE: implementation dependencies (was Re: ES4 work)

Lars Hansen-3
In reply to this post by Graydon Hoare-3
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Graydon Hoare
> Sent: 22. februar 2008 09:43
> To: Brendan Eich
> Cc: Michael O'Brien; es4-discuss Discuss; Dave Herman
> Subject: Re: implementation dependencies (was Re: ES4 work)
>
> 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.

The spec sources will be written using the mixed HTML/Wiki notation that
is already used by the draft library spec, see what's in the monontone
repository if you're curious (spec/library).

That should however not be a concern to most people who want to
contribute draft spec(let)s, since the actual markup is mainly a problem
for the editors.  On the other hand, the more magic software that is
used to produce speclets, the more pain it is for us to extract it into
the actual spec.  So be kind.  Text and/or wiki notation (whatever
flavor) is best.  

(I have written some speclets myself that I will post here if the
present discussion ever subsides, and I have used plain text.)

--lars
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
12