Re: strict mode becomes use subset cautious

[Maciej Stachowiak]

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: [EMAIL PROTECTED] x-discuss; es4-discuss@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 

RE: strict mode becomes use subset cautious

[Lars Hansen]

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: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Maciej
Stachowiak
Sent: 27. juni 2008 01:33
To: Allen Wirfs-Brock
Cc: [EMAIL PROTECTED] x-discuss; es4-discuss@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: [EMAIL PROTECTED] x-discuss; es4-discuss@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