implementation dependencies (was Re: ES4 work)

Michael O'Brien mob at
Thu Feb 21 23:40:31 PST 2008

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.



More information about the Es4-discuss mailing list