"strict mode" becomes "use subset cautious"

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"

_____________________________________________
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

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

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

There has been no discussion in the ES4 WG about adopting the ES3.1
convention in this matter.  I don't think that a list of subset
violations exists.  The closest thing we have is probably my response to
the 11 June draft of ES3.1, in which I pointed out all the problems I
could see at the time.

 

(A bit of a rant this, but speaking for myself, I object to the strongly
ideological slant of some of the ideas that have gone into the current
ES3.1 strict mode, such as disallowing semicolon insertion in strict
mode, and I see the inclusions of features like that as another real
problem with the subset relation.  In the past the ES4 WG has tried to
avoid cosmetic changes to the language, and we've also been skeptical of
changes that increase the tax of moving to strict mode.  We want strict
mode to be used, which means striking a balance between safety and
convenience.  It is possible that 3 programs out there have bugs caused
by optional semicolon insertion.  But it also likely that 3 million
programs will not be ported to (or written to) strict mode if semicolon
insertion is disallowed.)

 

--lars

 

From: es3.x-discuss-bounces at mozilla.org
[mailto:es3.x-discuss-bounces at mozilla.org] On Behalf Of Maciej
Stachowiak
Sent: 27. juni 2008 01:33
To: Allen Wirfs-Brock
Cc: es3.x-discuss at mozilla.org x-discuss; es4-discuss at mozilla.org
es4-discuss
Subject: Re: "strict mode" becomes "use subset cautious"

 

 

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/20080627/023e3ae5/attachment-0002.html

I  believe that identification of such a list  is something that we (ES3.1 and ES4) are going to have to work on together.  Getting the 3.1 draft. largely complete should be an enabler to get that started.  Resolution is also a two way street that is also going to require joint work.

We're working to get a technically complete draft out by the middle of next week so people can start reviewing it in preparation for Oslo.  There is a fair chance that we won't get the "formal" specification work done for a couple for features by then.  If that proves to be the case we intend to include a summary description of the missing features and then follow that up with spec. supplements covering those features as quickly as we can.

From: Maciej Stachowiak [mailto:mjs at apple.com]
Sent: Thursday, June 26, 2008 4:33 PM
To: Allen Wirfs-Brock
Cc: es3.x-discuss at mozilla.org x-discuss; es4-discuss at mozilla.org es4-discuss
Subject: Re: "strict mode" becomes "use subset cautious"


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<mailto:es3.x-discuss at mozilla.org> x-discuss; es4-discuss at mozilla.org<mailto: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<mailto:crock at yahoo-inc.com>; Mark S. Miller; Kris Zyp; Mike Cowlishaw; Adam Peller; Sam Ruby; Lars Hansen; ggaren at apple.com<mailto: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<mailto: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/b5caefee/attachment-0002.html

Lars,

You comments on the 6/11 draft have been very useful. You haven't heard anything back on most of those items because I've either just fixed them (or at least have them on my queue of things to fix) or decided that it was just a point of stylistic disagreed.   I'll eventually get around to listing what appear to be any remaining points of substantive disagreement.

Regarding your rant, I suspect that you'd agree that all designs to some degree or another has some ideological reflections.  It's also the case that in a collaborative design effort not every participant places the same value on each idea.  As far as I'm concerned nothing is off the table for discussion.  What are you willing to trade for a semi-colon here or there? :-)

The differences between the ES3.1 and ES 4 conceptions of "strict mode" has been one of the recent friction points between the two efforts.  While there is some overlap between these two different conceptions of "strict modes" there also seems to be some substantial differences, including the ideological ones you observe. The 3.1 working groups seems to be building a pretty firm consensus around the "use subset" formulation as it appears to offer a conceptually clearer and more future proof way to deal with the sort of optional restriction people are interested in imposing on the language.  I'd be happy to drill into it more with you.

Allen

From: Lars Hansen [mailto:lhansen at adobe.com]
Sent: Thursday, June 26, 2008 9:17 PM
To: Maciej Stachowiak; Allen Wirfs-Brock
Cc: es3.x-discuss at mozilla.org; es4-discuss at mozilla.org
Subject: RE: "strict mode" becomes "use subset cautious"

There has been no discussion in the ES4 WG about adopting the ES3.1 convention in this matter.  I don't think that a list of subset violations exists.  The closest thing we have is probably my response to the 11 June draft of ES3.1, in which I pointed out all the problems I could see at the time.

(A bit of a rant this, but speaking for myself, I object to the strongly ideological slant of some of the ideas that have gone into the current ES3.1 strict mode, such as disallowing semicolon insertion in strict mode, and I see the inclusions of features like that as another real problem with the subset relation.  In the past the ES4 WG has tried to avoid cosmetic changes to the language, and we've also been skeptical of changes that increase the tax of moving to strict mode.  We want strict mode to be used, which means striking a balance between safety and convenience.  It is possible that 3 programs out there have bugs caused by optional semicolon insertion.  But it also likely that 3 million programs will not be ported to (or written to) strict mode if semicolon insertion is disallowed.)

--lars

From: es3.x-discuss-bounces at mozilla.org [mailto:es3.x-discuss-bounces at mozilla.org] On Behalf Of Maciej Stachowiak
Sent: 27. juni 2008 01:33
To: Allen Wirfs-Brock
Cc: es3.x-discuss at mozilla.org x-discuss; es4-discuss at mozilla.org es4-discuss
Subject: Re: "strict mode" becomes "use subset cautious"


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<mailto:es3.x-discuss at mozilla.org> x-discuss; es4-discuss at mozilla.org<mailto: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<mailto:crock at yahoo-inc.com>; Mark S. Miller; Kris Zyp; Mike Cowlishaw; Adam Peller; Sam Ruby; Lars Hansen; ggaren at apple.com<mailto: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<mailto: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/174f7f56/attachment-0002.html