"strict mode" becomes "use subset cautious"

Maciej Stachowiak mjs at apple.com
Thu Jun 26 16:32:46 PDT 2008

On Jun 26, 2008, at 1:34 PM, Allen Wirfs-Brock wrote:

> At today’s ES 3.1 conference call (see http://wiki.ecmascript.org/doku.php?id=meetings:minutes_jun_24_2008) 
>  we agreed to adopt the essence of the proposal below and to use the  
> subset name “cautious” to referred to the set of restrictions  
> formerly known as “strict mode”

Will ES4 also be making this change? If not, we need to add it to the  
list of subset rule violations. Is anyone keeping such a list? Does  
the ES3.1 committee intend to address all such issues by the July  
timeframe that ES3.1 is apparently targetting?


> _____________________________________________
> From: Allen Wirfs-Brock
> Sent: Wednesday, June 25, 2008 12:38 PM
> To: Pratap Lakshman (VJ#SDK); Adam Peller; Sam Ruby; Mark S. Miller
> Cc: es3.x-discuss at mozilla.org x-discuss; es4-discuss at mozilla.org es4- 
> discuss
> Subject: RE: Brief Minutes [RE: ES3.1 WG phone conference 24 June  
> 08:00 PT]
> Following up on the “Strict Mode” discussion…
> As I advocated on the call, I think that by selecting “strict mode”  
> a developer is really choosing to restrict themselves to using a  
> subset of the complete language.  The future-proofing issues  of  
> this relate to the possibility that there might be multiple such  
> subsets that a developer might need to choose among.  Should there  
> be multiple named “strict modes” to choose among, how should they be  
> named, can “strictness” of a mode increase in future versions, etc?
> I think some of the controversy could be eliminated if we simply  
> eliminate the term “Strict Mode”.  Instead I propose we have a “Use  
> Subset” directive  and that we name specific subsets in a meaningful  
> and generally positive manner.  For example,  since the motivation  
> of most of the proposed restrictions in ES3.1 strict mode is to  
> provide a safer subset language I suggest that we call this subset  
> “safety”  (or perhaps “safety1” or “safetyA”  or “safety2008”  
> implying that in the future different safe subsets might be defined  
> and we don’t want to give undo importance to this initial one).
> So, the first line of a “strict mode” compilation unit would now  
> look like”
>         “use subset safety”
> I would suggest that we actually define “use subset” such that a  
> comma separated list of subsets is allowed.  So, if somebody decided  
> to define a subset that only contained the features of ES3 you might  
> see something like this:
>         “use subset safety,ES3”
> Since subsets are sets of restrictions, listing multiple subsets  
> means to take the union of the restrictions imposed by all of the  
> listed subsets.  So “use subset safty,ES3” means that this  
> compilation unit may only use those features defined by ECMA 262-3  
> and which are not excluded by the “safety” subset.  So, assuming  
> that “safety” excludes use of the with statement, such a compilation  
> unit could not include use of the with statement nor could it  
> include any use of a feature that is new in ES3.1 or ES4.
> Future versions of ECMAScript may add exclusions to a subset defined  
> by an earlier version as long as the added exclusions only restrict  
> capabilities that didn’t exist in the earlier version. For example,  
> ES 4 in supporting the ES3.1 “safety” subset but add to it any  
> features that are added in ES 4  but which are considered to be  
> unsafe.
> A future version may not add  exclusion to an pre-existing subset  
> that restricts features that existed when the original subset was  
> defined.  For example if ES3.14 or ES5 decided that the for-in  
> statement was unsafe, it could not add that restriction to the  
> “safety” subset.  However, it could define a new subset named  
> perhaps “safety2010” that includes all the restrictions of the  
> “safety” subset and in addition disallows use of the “for” statement.
> If a compilation unit specifies a subset that is not known to the  
> implementation that is processing it, that subset restriction is  
> simply ignored. The code in the unit is still either valid or  
> invalid on its own merit just like is the case when no subset had  
> been specified.
> _____________________________________________
> From: Pratap Lakshman (VJ#SDK)
> Sent: Tuesday, June 24, 2008 11:43 AM
> To: Adam Peller; Sam Ruby; Mark S. Miller; Allen Wirfs-Brock; Pratap  
> Lakshman (VJ#SDK)
> Subject: Brief Minutes [RE: ES3.1 WG phone conference 24 June 08:00  
> PT]
> Here are brief minutes from our call.
> Please take a look, and let me know if you want any changes by your  
> EOD.
> I’ll upload it to the wiki and send a copy to Patrick Charollais  
> (ECMA) for posting on the ECMA site tomorrow night (Redmond time).
> Attendees
> Adam Peller (IBM)
> Sam Ruby (IBM)
> Mark Miller (Google)
> Allen Wirfs-Brock (Microsoft)
> Pratap Lakshman (Microsoft)
> Agenda
> On posting the latest draft to the wiki
> Getters/Setters
> Decimal
> Setting up a review based on Lars' feedback on the 11 June draft
> Minutes
> Would like to add a couple more items to agenda that we can get to  
> if we have the time (1) inconsistence language like "as if by the  
> expression …" pervasive in ES3 (e.g. section 11.1.4 Array  
> Initializer: "create a new array as if by the expression new  
> Array()"; needs to be fixed in ES3.1 (2) ES3/ES4 based review.
> On posting the latest draft to the wiki
> The latest draft has been uploaded to the wiki. This the draft as of  
> 24 June 2008 - it has all the edits related to the statics on  
> Object, the introduction of the [[Extensible]] property, the revised  
> notation for JSON, and placeholders for Decimal - by next week we  
> should try to have a technically complete draft - the draft may  
> still have some place holders but it should still be enough to get  
> circulated within TC39 as an artifact that can be reviewed - by the  
> time we meet in Oslo, each place holder must have a supplementary  
> doc that can be discussed F2F.
> 'const' needs to be introduced into the grammar - what does it mean  
> to be a reserved word? - you cannot use it as a variable name - note  
> that we have introduced the ability to use is as the name of a  
> property though – const has letrec like  scoping – not subject to  
> hoisting.
> reformed scoping needs to be introduced - but for doing that we may  
> want to introduce the notion of a 'block activation' as an  
> expository device
> ‘abc’[i] is using the ES3 like algorithm convention – can we use the  
> new convention that eliminates the need for writing gotos – pratapL  
> to investigate – also, for all new functionality we need to worry  
> about argument conditioning – for e.g. if an algorithm expects to be  
> handed an object, make sure we call toObject on the argument that is  
> passed in.
> Getters/Setters
> Surface syntax spec from Kris looked Ok - need to ensure it is using  
> the Meta APIs - Allen to check surface syntax integration.
> Decimal
> Decimal changes are isolated and can be done without impacting  
> content in the rest of the doc - Sam can use the latest draft from  
> the wiki as a starting point.
> Strict mode
> 2 controversies coupled to each other – proposed ES4 wants to keep  
> ‘with’ in their strict mode; ES3.1 wants to remove ‘with’ in its  
> strict mode – need to be clear about the purpose of strict mode –  
> the other is “what do we mean by subset?” – there was one formal  
> definition from Lars, and Doug had called out a less formal notion –  
> we may end up using Doug’s less formal notion (especially if we  
> cannot resolve the ‘with’ issue).
> Binary strict mode is naively limiting – each version may want to  
> allow/limit specific features – strict mode allows users to say ‘I  
> am subscribing to this particular subset, and I am aware of all its  
> limitations’ – but if the subset is a moving target how do they do  
> that? - sure, we can introduce a more elaborate mechanism – it would  
> make it easier for us to not have to resolve arguments – but it  
> would open up a larger combinatorial space of possibilities – the  
> SunOS vs. MacOS problem; the former was highly customizable, however  
> you invariably got it wrong; the latter was not customizable, but  
> what you got was good enough to get the job done – more knobs need  
> not mean better.
> An elaborate mechanism enables chaos at the composability boundary –  
> but how does it matter if you are opaquely including a module? –  
> Caja will use ES3.1 strict mode for all uncajoled code – OTOH an  
> elaborate mechanism can enforce a subsetting profile – languages can  
> now more directly enforce Caja like semantics.
> ‘use strict 3.1’ could be a potential syntax to turn on 3.1 level  
> strict mode – with the possibility that the 3.1 may be replaced with  
> a list – instead of tying it to the language version number, we can  
> also just say something like ‘use strict a’ or ‘use strict 1’ – can  
> also use Perl-style ‘use strict no with’ (where we mention the  
> specific restriction we want to enable) – that seems a good idea too  
> – in any case, named restriction sets for ES3.1 and proposed ES4  
> will be useful to discuss this proposal further.
> Meeting adjourned.
> pratap
> _____________________________________________
> From: Pratap Lakshman (VJ#SDK)
> Sent: Tuesday, June 24, 2008 6:46 PM
> To: Pratap Lakshman (VJ#SDK); crock at yahoo-inc.com; Mark S. Miller;  
> Kris Zyp; Mike Cowlishaw; Adam Peller; Sam Ruby; Lars Hansen; ggaren at apple.com 
> ; Allen Wirfs-Brock
> Subject: ES3.1 WG phone conference 24 June 08:00 PT
> Agenda:
> (1) On posting the latest draft to the wiki
> (2) Getters/Setters
> (3) Decimal
> (4) setting up a review based on Lars' feedback on the 11 June draft
> Let me know if you want to add any items to the agenda
> Here is the dial-in information for our phone conference at 08:00 AM  
> (PT):
> Tel: 866 500 6738 (US); 203 480 8000 (intl)
> Participant code: 885535
> pratap
> _______________________________________________
> Es3.x-discuss mailing list
> Es3.x-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es3.x-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20080626/46839e98/attachment-0002.html 

More information about the Es4-discuss mailing list