implementation dependencies (was Re: ES4 work)

Brendan Eich brendan at mozilla.org
Thu Feb 21 23:26:41 PST 2008


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



More information about the Es4-discuss mailing list