ES3.1: Draft 1

[Brendan Eich-2]

On Jun 16, 2008, at 8:39 AM, Mark S. Miller wrote:

> On Sat, Jun 14, 2008 at 11:43 PM, Garrett Smith  
> <dhtmlkitchen@...> wrote:
>> The spec doesn't mention that FunctionExpression with Identifier can
>> affect scope chain. Example:-
>>
>> (function f() {
>>  var propertyIsEnumerable = 0;
>>  (function f() {
>>        alert(propertyIsEnumerable); //=> native code
>>  })();
>> })();
>
>
> Hi Garrett, thanks for alerting us to this bizarre behavior. I had no
> idea.

Lars included it in "Compatibility Between ES3 and Proposed ES41",  
section 1.6, although the example there shows only the catch variable  
case. IIRC, Pratap pointed the problem out well over a year ago, but  
I can't find the reference at the moment.

> I did reproduce this behavior and minor variants. However,
> oether variants didn't work, indicating that I don't yet understand
> what's happening here. For example, on Firefox 2.0.0.14 in squarefree:
>
>     var g = function f() { return x; }
>
>     g()
>     ReferenceError on line 1: x is not defined
>
>     g.x = 3;
>     3
>
>     g()
>     ReferenceError on line 1: x is not defined
>
> As I thought I understood this example, I would have expected the last
> call to g() to return 3. Can someone explain why it doesn't?

Ad-hoc properties on the function object do not show up as variables  
referenced lexically, the bug is different. ES3 says (13, third  
production's semantics):

The production FunctionExpression : function Identifier  
( FormalParameterListopt ) { FunctionBody } is evaluated as follows:
1. Create a new object as if by the expression new Object().
2. Add Result(1) to the front of the scope chain.
3. Create a new Function object as specified in section 13.2 with  
parameters specified by FormalParameterListopt and body specified by  
FunctionBody. Pass in the scope chain of the running execution  
context as the Scope.
4. Create a property in the object Result(1). The property's name is  
Identifier, value is Result(3), and attributes are { DontDelete,  
ReadOnly }.
5. Remove Result(1) from the front of the scope chain.
6. Return Result(3).

Therefore one bad case for a named function expression goes like this:

js> var g = function f(){return x}
js> Object.prototype.x = 'wrong'
wrong
js> var x = 'right'
js> g()
wrong

Garrett showed an example using a standard property of  
Object.prototype, propertyIsEnumerable.

Worse, the ES3 spec says "as if by the expression new Object()". So  
by the book, one could do this (doesn't work in Firefox, Opera,  
perhaps others who wisely ignore the spec):

js> var fake = {x:'fake'}
js> Object = function(){return fake}
js> var g = function f(){return x}
js> g()
fake

but you would need to be careful to restore Object to  
fake.constructor or equivalent before going too far.

http://wiki.ecmascript.org/doku.php?id=clarification:which_prototype

talks about the inconsistencies in ES3 between "original value  
of ..." and "as if by the expression".

/be
_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Brendan Eich-2]

On Jun 16, 2008, at 10:49 AM, Brendan Eich wrote:

> Lars included it in "Compatibility Between ES3 and Proposed ES41",

Meant to write "Compatibility Between ES3 and Proposed ES4[1]" there.  
No ES4.1 or ES41 in sight!

/be

[1] http://www.ecmascript.org/es4/spec/incompatibilities.pdf

_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Lars Hansen-3]

Intuitively the "subset relation" is determined by the rule that a
processor for version n+d (for d > 0 but not necessarily integer or
indeed rational...) of the language should accept all programs P valid
under version n, and P should evaluate to the same results in version
n+d, except that P may have to be rewritten if:

 1  P uses an identifier that became a keyword in n+d

 2  P makes use of a feature that changed behavor in n+d due to a "bug
fix"

 3  P (or portions of P) is strict, n+d has a stricter strict mode than
n,
    and P runs afoul of a feature that has been firmed up in n+d

 4  P introduces a variable or property on a built-in object or type but
n+d
    has introduced a variable or property of the same name

 5  P relies on exceptions that are thrown by a version n language
processor
    because portions of P are invalid (typically, syntax errors)

Item 1 is handled by opt-in; a version n+d processor is expected to
process a version n program by not recognizing keywords introduced in
n+d, but otherwise treat the program as a version n+d program.

Item 2 has been discussed extensively; the rule of thumb for a bug fix
is that the change must fix many more programs than it breaks.  The
canonical example is the handling of regular expression literals, which
are evaluated once in ES3 programs but every time they are reached
during evaluation in ES4 (and in ES3.1 as far as I could tell from the
latest draft), but a long list is given on the wiki:
http://wiki.ecmascript.org/doku.php?id=proposals:bug_fixes.  (Some of
those are still too big to be simple bug fixes, and some are no longer
approved for inclusion, but most are still good.)

Item 3 hasn't been discussed much, but during the last meeting Brendan,
Mark, and I did talk about it and agreed that it would be OK for strict
modes to become stricter as the language version goes up.  The example
in question was the way ES3.1 wants to deal with number-of-arguments
checking in strict mode: it wants to allow a mismatching number of
arguments in strict mode only if the arguments object is mentioned
explicitly in the program text.  That is a hack not required for ES4,
which has syntax for optional parameters and explicit rest parameters,
and which will want to disallow a mismatching number of arguments in
strict mode in all cases (in other words, there will be limited uses for
the arguments object in ES4 strict mode).

Items 4 and 5 are sanctioned by the ES3 spec (Chapter 16).  In ES4, all
new global names are in the __ES4__ namespace in order to reduce the
risk associated with introducing new global names.

The issue that was raised by the discussion quoted below was whether
strict mode could become /looser/ as the language version goes up; could
ES3.1 outlaw 'with' in strict mode, but ES4 allow it again?  This feels
weird to me.

--lars

> -----Original Message-----
> From: es3.x-discuss-bounces@...
> [mailto:es3.x-discuss-bounces@...] On Behalf Of Lars Hansen
> Sent: 12. juni 2008 21:25
> To: Sam Ruby
> Cc: es3.x-discuss@...; es4-discuss@...
> Subject: RE: ES3.1 Draft: 11 June 2008 version available
>
> Fair question.  I don't recall that it has been spelled out carefully,
> actually.  I'll take a stab at it in the morning.  (Also, the ES3 ->
> ES3.1 and ES3 -> ES4 relationships are important.)  Any useful
> definition will have to deal with bugfixes and security fixes (like
> global type names being read-only under some circumstances in ES4).
>
> --lars
>
> > -----Original Message-----
> > From: sa3ruby@... [mailto:sa3ruby@...] On Behalf
> > Of Sam Ruby
> > Sent: 12. juni 2008 18:46
> > To: Lars Hansen
> > Cc: es3.x-discuss@...; es4-discuss@...
> > Subject: Re: ES3.1 Draft: 11 June 2008 version available
> >
> > I'm trying to understand the nature of the ES3.1 - ES4 subset
> > relationship that this committee has agreed to.
> >
> > > p69 12.10.  Disallowing the with statement in strict mode
> breaks the
> > > ES3.1 - ES4 subset relationship (we've found no compelling
> > reason to
> > > ban it).
> >
> > How does having ES4 support *more* than ES3.1 supports break
> > the subset relationship?
> >
> > - Sam Ruby
> >
> _______________________________________________
> Es3.x-discuss mailing list
> Es3.x-discuss@...
> https://mail.mozilla.org/listinfo/es3.x-discuss
>

_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Douglas Crockford]

>The issue that was raised by the discussion quoted below was whether
>strict mode could become /looser/ as the language version goes up; could
>ES3.1 outlaw 'with' in strict mode, but ES4 allow it again?  This feels
>weird to me.

The thing that needs to be maintained is the viability of programs that are written without anticipation of the characteristics of future standards. I don't think that needs to include the strict interpretation of what the strict mode disallows. For ES3.1, strict mode indicates that the programmer wants to use a more reliable subset of the language. If ES4's objectives are different, I think it can have its own definition of strict mode.

I agree that it is weird that ES4 wants to retain with, but that in itself does not disturb the superset relationship.
_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Mark S. Miller-2]

On Mon, Jun 16, 2008 at 2:07 PM, Douglas Crockford
<douglas@...> wrote:
> I agree that it is weird that ES4 wants to retain with, but that in itself does not disturb the superset relationship.

Before we retreat into less formal notions of subsetting, could
someone please explain why ES4 wants to retain "with" in ES4 strict
mode?


--
    Cheers,
    --MarkM
_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Mark S. Miller-2]

On Mon, Jun 16, 2008 at 2:45 PM, Mark S. Miller <erights@...> wrote:
> On Mon, Jun 16, 2008 at 2:07 PM, Douglas Crockford
> <douglas@...> wrote:
>> I agree that it is weird that ES4 wants to retain with, but that in itself does not disturb the superset relationship.
>
> Before we retreat into less formal notions of subsetting, could
> someone please explain why ES4 wants to retain "with" in ES4 strict
> mode?


Given the silence, I thought it might be worth pointing out:

* "Reformed with" was dropped from ES4 strict because it wasn't enough
less horrible than "with" to be worth it. If "reformed with" isn't
good enough, does anyone think "with" is somehow better than "reformed
with"?

* Given Brendan's and Maciej's clarifications, it seems that "with" is
the *only* remaining feature of ES4 strict preventing static scope
analysis.

If the ES4 folks still wish to include "with" in ES4 strict, perhaps
they can clarify what they see as the purpose of strict mode. Because
I'm completely baffled.

--
    Cheers,
    --MarkM
_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Maciej Stachowiak]

On Jun 16, 2008, at 8:09 PM, Mark S. Miller wrote:

> On Mon, Jun 16, 2008 at 2:45 PM, Mark S. Miller <erights@...>  
> wrote:
>> On Mon, Jun 16, 2008 at 2:07 PM, Douglas Crockford
>> <douglas@...> wrote:
>>> I agree that it is weird that ES4 wants to retain with, but that  
>>> in itself does not disturb the superset relationship.
>>
>> Before we retreat into less formal notions of subsetting, could
>> someone please explain why ES4 wants to retain "with" in ES4 strict
>> mode?
>
>
> Given the silence, I thought it might be worth pointing out:
>
> * "Reformed with" was dropped from ES4 strict because it wasn't enough
> less horrible than "with" to be worth it. If "reformed with" isn't
> good enough, does anyone think "with" is somehow better than "reformed
> with"?
>
> * Given Brendan's and Maciej's clarifications, it seems that "with" is
> the *only* remaining feature of ES4 strict preventing static scope
> analysis.
>
> If the ES4 folks still wish to include "with" in ES4 strict, perhaps
> they can clarify what they see as the purpose of strict mode. Because
> I'm completely baffled.

I can't speak for the main ES4 designers, and I don't personally see  
why "with" needs to be supported in strict mode. But I imagine the  
reasoning goes like this:

- Strict mode is a "good taste" mode, like Perl's "use strict", not a  
mode designed to give any specific guarantees about analyzability
- "with" is popular among JavaScript authors today, and even in JS  
libraries, so:
    - it would be hard to declare it beyond the boundaries of good taste
    - it would needlessly inhibit adoption of strict mode to have it

I would personally consider "with" to be in bad taste, notwithstanding  
its popularity.

Regards,
Maciej

_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Brendan Eich-2]

On Jun 16, 2008, at 8:09 PM, Mark S. Miller wrote:

> On Mon, Jun 16, 2008 at 2:45 PM, Mark S. Miller  
> <erights@...> wrote:
>> On Mon, Jun 16, 2008 at 2:07 PM, Douglas Crockford
>> <douglas@...> wrote:
>>> I agree that it is weird that ES4 wants to retain with, but that  
>>> in itself does not disturb the superset relationship.
>>
>> Before we retreat into less formal notions of subsetting, could
>> someone please explain why ES4 wants to retain "with" in ES4 strict
>> mode?
>
>
> Given the silence,

I am not going to repeat what I wrote at an earlier point in this  
thread (13 June at 10:24) -- you didn't reply to what I wrote then.  
Did that message not reach you?


> I thought it might be worth pointing out:
>
> * "Reformed with" was dropped from ES4 strict because it wasn't enough
> less horrible than "with" to be worth it.

That's not the reason for dropping it. It was considered sufficient  
to migrate existing 'with' into, as well as support novel 'with' uses  
under, ES4 strict mode -- without loss of lexical scope. But it was  
not cheap (requiring invariant type checking), and it was a special  
case that could be cut without affecting the core language. The  
degree to which it would be used was open to debate. Again, is the  
carrot of strict mode worth the stick of adding type annotations to  
'with' heads?

Forbidding 'with' in strict mode raises the "rewrite tax" beyond an  
addition to the 'with' head, requiring analysis and rewriting to use  
a short-hand let binding to denote the head object. There is no "let  
ref" (Modula 3); it's not enough to destructure object properties  
into individual same-named let bindings, because mutations won't  
update the object's properties.


> If "reformed with" isn't
> good enough, does anyone think "with" is somehow better than "reformed
> with"?

The question isn't whether an existing statement is "good enough",  
it's whether a strict mode that bans it is "usable enough".


> * Given Brendan's and Maciej's clarifications, it seems that "with" is
> the *only* remaining feature of ES4 strict preventing static scope
> analysis.

The global object still allows new names to be usable via lexical  
references, where the names were not bound at static analysis  
(compile) time.


> If the ES4 folks still wish to include "with" in ES4 strict, perhaps
> they can clarify what they see as the purpose of strict mode. Because
> I'm completely baffled.

Methinks you protest too much. You are right to point to reformed  
with, since it was my idea for making with tolerable to an earlier  
notion of 'use strict' -- strict mode as a verifier, which would need  
to see name bindings in order to do type checking.

This old notion of strict mode was to be an optional feature, at the  
implementation's discretion. We dropped it in favor of 'use strict' a  
la Perl -- "use good taste and sanity". Without type checking, the  
argument against unreformed 'with' is reduced to one about static  
scope -- but the global object still frustrates static scope, so is  
kicking 'with' out of strict mode worth it, especially if it impairs  
adoption of "use strict"?

/be

_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Mark S. Miller-2]

On Mon, Jun 16, 2008 at 10:19 PM, Brendan Eich <brendan@...> wrote:
> I am not going to repeat what I wrote at an earlier point in this thread (13
> June at 10:24) -- you didn't reply to what I wrote then. Did that message
> not reach you?

Are you referring to
<https://mail.mozilla.org/pipermail/es3.x-discuss/2008-June/000108.html>?
It was the closest match I could find. I responded to this message.
What remaining point in this message do you feel still needs to be
addressed? I'm not being difficult. I just reread this message and
couldn't spot it.



>> If "reformed with" isn't
>> good enough, does anyone think "with" is somehow better than "reformed
>> with"?
>
> The question isn't whether an existing statement is "good enough", it's
> whether a strict mode that bans it is "usable enough".

A strict mode which doesn't ban is clearly not.


>> * Given Brendan's and Maciej's clarifications, it seems that "with" is
>> the *only* remaining feature of ES4 strict preventing static scope
>> analysis.
>
> The global object still allows new names to be usable via lexical
> references, where the names were not bound at static analysis (compile)
> time.

If you get rid of "with", then the static analysis rule in ES4 becomes
very simple: all free variables in a program (script, compilation
unit, whatever) are global references, to be looked up as properties
of that program's global object, whether or not those properties are
present.

>> If the ES4 folks still wish to include "with" in ES4 strict, perhaps
>> they can clarify what they see as the purpose of strict mode. Because
>> I'm completely baffled.
>
> Methinks you protest too much. You are right to point to reformed with,
> since it was my idea for making with tolerable to an earlier notion of 'use
> strict' -- strict mode as a verifier, which would need to see name bindings
> in order to do type checking.
>
> This old notion of strict mode was to be an optional feature, at the
> implementation's discretion. We dropped it in favor of 'use strict' a la
> Perl -- "use good taste and sanity".

And is "with" either in good taste or sane?

>  Without type checking, the argument
> against unreformed 'with' is reduced to one about static scope -- but the
> global object still frustrates static scope,

The global object makes the contents of the global scope unknown. But
it does not ambiguate which variable name occurences are to be
interpreted as references into this global scope. Without "with", ES4
strict scopes would be statically analyzable. I'm surprised you're
willing to give that up.


> so is kicking 'with' out of
> strict mode worth it, especially if it impairs adoption of "use strict"?

Yes. Otherwise I don't see the point of "use strict".

--
    Cheers,
    --MarkM
_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Brendan Eich-2]

On Jun 16, 2008, at 10:48 PM, Mark S. Miller wrote:

On Mon, Jun 16, 2008 at 10:19 PM, Brendan Eich <brendan@...> wrote:

I am not going to repeat what I wrote at an earlier point in this thread (13

June at 10:24) -- you didn't reply to what I wrote then. Did that message

not reach you?

Are you referring to

<https://mail.mozilla.org/pipermail/es3.x-discuss/2008-June/000108.html>?

Yes.

It was the closest match I could find. I responded to this message.

What remaining point in this message do you feel still needs to be

addressed? I'm not being difficult. I just reread this message and

couldn't spot it.

You replied only to the bit about reformed with, where I wrote:

"Reformed with" was an attempt to restore lexical scope by exact type annotation. That's what people voted down, not the ES1-3 "with" statement.

but that was not the main point (since reformed with was withdrawn), it was just setting the record straight ("reformed with", not "strict with" -- and the fact that it was voted down with red on the spreadsheet does not argue against plain old "with" being allowed in strict mode).

The main point was that (a) 'with' is widespread and popular; therefore (b) strict mode that bans 'with' could fail to be used.

The question isn't whether an existing statement is "good enough", it's

whether a strict mode that bans it is "usable enough".

A strict mode which doesn't ban is clearly not.

Why "clearly"? Usability depends on users and "ergonomics". Something about 'with' is usable enough that users persist in writing programs using it. These users say (when they speak up coherently at all) that 'with' makes the language more convenient. Well-known JS hackers say this, to me even, and get annoyed by nagging such as was found in older Firefoxes (console warnings about "deprecated with").

If you get rid of "with", then the static analysis rule in ES4 becomes

very simple: all free variables in a program (script, compilation

unit, whatever) are global references, to be looked up as properties

of that program's global object, whether or not those properties are

present.

That allows lexical-reference typos through to run-time, where they become errors -- that is not something the old, withdrawn strict mode in ES4 allowed.

It's true that 'with' prevents analysis from deciding where a free name will be found, but with the old strict mode, that's actually a useful escape hatch. Otherwise (no 'with') the name would have to resolve to a compiler-visible global definition, or you would have to reach for eval.

This old notion of strict mode was to be an optional feature, at the

implementation's discretion. We dropped it in favor of 'use strict' a la

Perl -- "use good taste and sanity".

And is "with" either in good taste or sane?

I avoid 'with', but I try not to confuse my taste with others' tastes (plural), or with necessity. Why is it necessary for strict mode to ban 'with'?

The global object makes the contents of the global scope unknown. But

it does not ambiguate which variable name occurences are to be

interpreted as references into this global scope. Without "with", ES4

strict scopes would be statically analyzable. I'm surprised you're

willing to give that up.

As I wrote previously, all browser implementations have to support 'with' and deoptimize code in its body. There's no savings to be had in rejecting it from strict mode, and doing so takes a tiny bit of extra code. On the other hand, such a strict mode may be less used than 'with', because of 'with' perduring.

Is 'with' any worse than eval, for the purposes of the analysis you have in mind, if you already allow the "operator" form of eval in strict mode?

so is kicking 'with' out of

strict mode worth it, especially if it impairs adoption of "use strict"?

Yes. Otherwise I don't see the point of "use strict".

Can you define the point of "use strict" other than by appealing to taste?

/be

_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Pratap Lakshman (VJ#SDK)]

Some parts of this message have been removed. Learn more about Nabble's security policy.

I have uploaded to the wiki (link, see under "Draft Specification") the current draft of the specification for ES3.1. This is in the form of in-place edits and markups to the ES3 specification (specifically, on the 11 June draft). Revision history is at the end of the document.

 

I have not yet incorporated the review comments you sent on the 11 June draft. For the moment I am focusing on incorporating normative content, but will certainly address all of your review comments in upcoming drafts.

 

pratap

_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Lars Hansen-3]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Is there a changelog between successive ES3.1 drafts?

 

--lars

 

From: es3.x-discuss-bounces@... [mailto:es3.x-discuss-bounces@...] On Behalf Of Pratap Lakshman (VJ#SDK)
Sent: 26. juni 2008 22:23
To: es3.x-discuss@...
Cc: es4-discuss@...
Subject: ES3.1 Draft: 24 June 2008 version available

 

I have uploaded to the wiki (link, see under "Draft Specification") the current draft of the specification for ES3.1. This is in the form of in-place edits and markups to the ES3 specification (specifically, on the 11 June draft). Revision history is at the end of the document.

 

I have not yet incorporated the review comments you sent on the 11 June draft. For the moment I am focusing on incorporating normative content, but will certainly address all of your review comments in upcoming drafts.

 

pratap

_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Allen Wirfs-Brock-2]

Some parts of this message have been removed. Learn more about Nabble's security policy.

So far, we’ve been trying to primarily track changes relative to the original ES3 spec. and that is how we intend to release next week’s version.  However, we can probably create you a version that shows the delta’s relative to the June 11 version if that would be helpful.  I think after next week’s release will probably be the right point to start trying to maintain a change log.

 

I wouldn’t recommend putting much energy into the June 24 version as that is just a working draft that is not very clean or complete.  

 

From: es4-discuss-bounces@... [mailto:es4-discuss-bounces@...] On Behalf Of Lars Hansen
Sent: Thursday, June 26, 2008 9:18 PM
To: Pratap Lakshman (VJ#SDK); es3.x-discuss@...
Cc: es4-discuss@...
Subject: RE: ES3.1 Draft: 24 June 2008 version available

 

Is there a changelog between successive ES3.1 drafts?

 

--lars

 

From: es3.x-discuss-bounces@... [mailto:es3.x-discuss-bounces@...] On Behalf Of Pratap Lakshman (VJ#SDK)
Sent: 26. juni 2008 22:23
To: es3.x-discuss@...
Cc: es4-discuss@...
Subject: ES3.1 Draft: 24 June 2008 version available

 

I have uploaded to the wiki (link, see under "Draft Specification") the current draft of the specification for ES3.1. This is in the form of in-place edits and markups to the ES3 specification (specifically, on the 11 June draft). Revision history is at the end of the document.

 

I have not yet incorporated the review comments you sent on the 11 June draft. For the moment I am focusing on incorporating normative content, but will certainly address all of your review comments in upcoming drafts.

 

pratap

_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss