ES4 work

Lars Hansen lhansen at adobe.com
Mon Feb 18 12:47:56 PST 2008


 


________________________________

	From: es4-discuss-bounces at mozilla.org
[mailto:es4-discuss-bounces at mozilla.org] 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
				Es4-discuss at mozilla.org
	
https://mail.mozilla.org/listinfo/es4-discuss
				
				  
				

			
			

		
		

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20080218/1246de72/attachment-0002.html 


More information about the Es4-discuss mailing list