implementation dependencies (was Re: ES4 work)
mob at mbedthis.com
Thu Feb 21 23:40:31 PST 2008
> 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
> 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
> 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