"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?
Regards,
Maciej
>
> _____________________________________________
> 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