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 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); [EMAIL PROTECTED]; Mark S. Miller;
Kris Zyp; Mike Cowlishaw; Adam Peller; Sam Ruby; Lars Hansen; [EMAIL PROTECTED]
; 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
[EMAIL PROTECTED]
https://mail.mozilla.org/listinfo/es3.x-discuss
_______________________________________________
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
