block scope + direct non-strict eval

Allen Wirfs-Brock allen at wirfs-brock.com
Thu Feb 2 08:33:23 PST 2012


On Feb 2, 2012, at 6:46 AM, Claus Reinke wrote:

>>> Okay, that wasn't clear to me from the meeting notes. In general,
>>> I've completely lost track of what ES6 is going to look like: too
>>> many variations and re-designs in the mailing list threads, no way
>>> for me to distinguish member preferences from committee
>>> agreements. As the wiki no longer seems to represent the latest
>>> agreements, I'll have to wait for your next spec update (and hope
>>> that there isn't another thread that obsoletes the spec update).
>> In general, the most definitive information is from Waldemar's notes
>> from the face-to-face TC39 meetings.  Much of what is discussed isn't
>> in the latest spec drafts (modules, for example), and the wiki is both
>> potentially out of date (sadly, this is especially true in things I'm
>> responsible for) and does not necessarily have the consensus of the
>> committee.  It's very rare that final designs can be gleaned directly
>> from the mailing list, even the mailing list posts of TC39 members.
>> Ultimately though, the overall shape of ES6 is fairly clear (see the
>> harmony:proposals page); conversely, many of the fine details haven't
>> been fully decided, so it's not possible to know how they'll turn out
>> yet.
> 
> If I could make a suggestion: 
>   directly after each f2f meeting, TC39 could go through the    harmony:proposals page and annotate every proposal that is    affected by decisions of that meeting (just the proposal entries
>   on that single top-level page, not the proposal texts).
> 
> For instance, if the no-opt-in decision means giving up on some proposals, annotate those with "obsolete after 19/01 meeting".
> Similarly, annotate other proposals as "needs update after 19/01" and add placeholders (eg. "no-opt-in") for "new proposal after 19/01", as needed.
> 
> That way, even if it takes time to update the actual proposal
> texts, the harmony:proposals overview page would always reflect the latest agreements and action items. Once the proposal texts
> are updated, change the annotations on harmony:proposals to "last updated 19/01" or whatever meeting last affected that proposal. In the same direction, have an icon for proposals
> that have been integrated into the latest spec draft.
> 
> Using the harmony:proposal page as the main "whiteboard",
> with links not only to proposals, but also to spec drafts and
> meeting notes, and with status/todo annotations, might help to put everyone onto the same page.

In general, my job as editor is to turn proposal into to actual normative specification language. Informally at any point in time, a wiki proposal is in one of three states relative to the draft ES6 specification.  The states "in the draft spec",. "not yet in the draft spec", or "draft spec. work in process". 

For proposal that are "in the draft spec", the spec should be the primary think you look at as it reflects my understanding of all current decisions and is the normative text that ultimately needs to be correct. Sometimes there are open issues that are explicitly noted in the draft.  I generally "immediately" (within a week or so) after a TC39 meeting update the draft spec. to reflect any decisions that were made concerning "in the draft spec features".  Once something is "in draft spec", the wiki pages become many useful as background material. 

I find that for most proposal there are many details that need to be specified that were not covered by the proposal.  I generally bring to this list any such details that have a significant impact, are likely to be controversial,  or for which that are multiple plausable alternatives.  But  for the rest I simply resolve them in a manner that I believe is most consistent with the overall language.  This is why it is important that people review the actual specification language. In the end, its the only thing that counts.

For  proposal that are "not yet in the draft spec", it would certainly be helpful if the champions of such proposal kept them up to date.

I treat proposals that are  "in process for the draft", similarly to "in the draft spec" items.  But it would be helpful for the champions to also update the proposal pages.

Bottom line, always start with the draft spec.  Then refer to proposals.

Allen









> 
> Claus
> 



More information about the es-discuss mailing list