RE: Subset relation (was: RE: ES3.1 Draft: 11 June 2008 version available)

[Pratap Lakshman (VJ#SDK)]

Since we are discussing 'with' in particular - it may be difficult to tighten 
spec language to fix 'with', but I do believe that if there is some way in 
which we can deprecate/ban 'with' we should consider it.

For e.g. 'with' interacts with other language features in surprising ways. 
Consider the following (contrived) case:

var a = 1;
function foo() {
var o = {a : 2};

with (o) {
var a = 3;
}

print (a);
print(o.a);
}
foo();
print(a);

While it would look like the variable declaration from within 'with' should 
create a variable at foo scope and set its value to 3, that's not what's 
supposed to happen. Rules for variable instantiation (§10.1.3), variable 
declaration grammar (§12.2), identifier reference (§11.1.2), and scope chain 
and identifier resolution (§10.1.4) result in the above code being evaluated as 
if it were the following:

var a = 1;
function foo() {
var o = {a : 2};
var a = undefined;

with (o) {
a = 3;
}

print(a);
print(o.a);
}
foo();
print(a);

Notice that "var a = 3" ends up creating the variable in one scope and setting 
the value on an element in another scope. How can that be intentional?
It may be difficult to tighten spec language to fix this, but we should 
consider deprecating/banning 'with' in an opt-in 'strict' mode (or 'subset' 
mode).

pratap

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brendan Eich
Sent: Tuesday, June 17, 2008 12:20 PM
To: Mark S. Miller
Cc: [EMAIL PROTECTED]; es4-discuss@mozilla.org; Douglas Crockford
Subject: Re: Subset relation (was: RE: ES3.1 Draft: 11 June 2008 version 
available)

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


On Mon, Jun 16, 2008 at 10:19 PM, Brendan Eich <[EMAIL PROTECTED]<mailto:[EMAIL 
PROTECTED]>> 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<https://mail.mozilla.org/pipermail/es3.x-discuss/2008-June/000109.html> 
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

Re: Subset relation (was: RE: ES3.1 Draft: 11 June 2008 version available)

[Brendan Eich]

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

On Mon, Jun 16, 2008 at 10:19 PM, Brendan Eich  
<[EMAIL PROTECTED]> 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
?


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@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Subset relation (was: RE: ES3.1 Draft: 11 June 2008 version available)

[Mark S. Miller]

On Mon, Jun 16, 2008 at 10:19 PM, Brendan Eich <[EMAIL PROTECTED]> 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
?
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@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Subset relation (was: RE: ES3.1 Draft: 11 June 2008 version available)

[Brendan Eich]

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

> On Mon, Jun 16, 2008 at 2:45 PM, Mark S. Miller  
> <[EMAIL PROTECTED]> wrote:
>> On Mon, Jun 16, 2008 at 2:07 PM, Douglas Crockford
>> <[EMAIL PROTECTED]> 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@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Subset relation (was: RE: ES3.1 Draft: 11 June 2008 version available)

[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 <[EMAIL PROTECTED]>  
> wrote:
>> On Mon, Jun 16, 2008 at 2:07 PM, Douglas Crockford
>> <[EMAIL PROTECTED]> 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@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Subset relation (was: RE: ES3.1 Draft: 11 June 2008 version available)

[Mark S. Miller]

On Mon, Jun 16, 2008 at 2:45 PM, Mark S. Miller <[EMAIL PROTECTED]> wrote:
> On Mon, Jun 16, 2008 at 2:07 PM, Douglas Crockford
> <[EMAIL PROTECTED]> 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@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Subset relation (was: RE: ES3.1 Draft: 11 June 2008 version available)

[Mark S. Miller]

On Mon, Jun 16, 2008 at 2:07 PM, Douglas Crockford
<[EMAIL PROTECTED]> 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@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

RE: Subset relation (was: RE: ES3.1 Draft: 11 June 2008 version available)

[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@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Subset relation (was: RE: ES3.1 Draft: 11 June 2008 version available)

[Lars Hansen]

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: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Lars Hansen
> Sent: 12. juni 2008 21:25
> To: Sam Ruby
> Cc: [EMAIL PROTECTED]; es4-discuss@mozilla.org
> 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf 
> > Of Sam Ruby
> > Sent: 12. juni 2008 18:46
> > To: Lars Hansen
> > Cc: [EMAIL PROTECTED]; es4-discuss@mozilla.org
> > 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
> [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

Re: ES3.1 Draft: 11 June 2008 version available

[Brendan Eich]

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@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: ES3.1 Draft: 11 June 2008 version available

[Brendan Eich]

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

> On Sat, Jun 14, 2008 at 11:43 PM, Garrett Smith  
> <[EMAIL PROTECTED]> 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@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: ES3.1 Draft: 11 June 2008 version available

[Mark S. Miller]

On Sat, Jun 14, 2008 at 11:43 PM, Garrett Smith <[EMAIL PROTECTED]> 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. 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?

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

Re: ES3.1 Draft: 11 June 2008 version available

[Brendan Eich]

On Jun 14, 2008, at 11:43 PM, Garrett Smith 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
>   })();
> })();

Both catch variables and named function expression bindings based on  
Object properties are bugs in ES3, fixed in ES4 proposals and specs  
for a while now, and fixed in some JS implementations (both cases are  
fixed in Opera, IIRC; catch variables are let-based in Firefox 2 and 3).

/be

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

Re: ES3.1 Draft: 11 June 2008 version available

[Garrett Smith]

On Sat, Jun 14, 2008 at 10:49 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
>
> On Jun 14, 2008, at 12:21 PM, Mark S. Miller wrote:
>
>> On Fri, Jun 13, 2008 at 2:44 PM, Mark Miller <[EMAIL PROTECTED]>
>> wrote:
>>> On Fri, Jun 13, 2008 at 11:20 AM, Lars Hansen <[EMAIL PROTECTED]>


> Named function expressions have the same kind of problem as try/catch
> (assuming the problem is a random non-activation object being on the
> scope chain).
>

On the front of the scope chain, in fact:-

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.

- This is stated in  10.1.4 Scope Chain and Identifier Resolution:
"During execution within an execution context, the scope chain of the
execution context is affected only by with statements (see 12.10) and
catch clauses (see 12.14)."

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
  })();
})();

Garrett


> Regards,
> Maciej
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: ES3.1 Draft: 11 June 2008 version available

[Maciej Stachowiak]

On Jun 14, 2008, at 12:21 PM, Mark S. Miller wrote:

> On Fri, Jun 13, 2008 at 2:44 PM, Mark Miller <[EMAIL PROTECTED]>  
> wrote:
>> On Fri, Jun 13, 2008 at 11:20 AM, Lars Hansen <[EMAIL PROTECTED]>  
>> wrote:
 What
 other "with" do people imagine is compatible with strict
 mode? I must have missed something.
>>>
>>> The one in ES3.  What makes it not compatible with strict mode?
>>
>> Doesn't it make static scope analysis impossible?
>
> Deleting a variable also makes static scope analysis impossible.
> (Deleting a property is fine.)

Deleting a variable is only possible for variables introduced by eval,  
and I gather eval will not be able to inject bindings into local scope  
in strict mode.

> Once try/catch is fixed, I can't think of anything else that prevents
> static scope analysis of ES3.1 strict or ES4 strict. Does anyone know
> of any other cases?

Named function expressions have the same kind of problem as try/catch  
(assuming the problem is a random non-activation object being on the  
scope chain).

Regards,
Maciej

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

Re: ES3.1 Draft: 11 June 2008 version available

[Mark S. Miller]

On Fri, Jun 13, 2008 at 2:44 PM, Mark Miller <[EMAIL PROTECTED]> wrote:
> On Fri, Jun 13, 2008 at 11:20 AM, Lars Hansen <[EMAIL PROTECTED]> wrote:
>>> What
>>> other "with" do people imagine is compatible with strict
>>> mode? I must have missed something.
>>
>> The one in ES3.  What makes it not compatible with strict mode?
>
> Doesn't it make static scope analysis impossible?

Deleting a variable also makes static scope analysis impossible.
(Deleting a property is fine.)

Once try/catch is fixed, I can't think of anything else that prevents
static scope analysis of ES3.1 strict or ES4 strict. Does anyone know
of any other cases?

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

Re: ES3.1 Draft: 11 June 2008 version available

[Mark Miller]

On Fri, Jun 13, 2008 at 11:32 AM, Mike Cowlishaw <[EMAIL PROTECTED]> wrote:
> Compared to many other notations that language standards committees
> consider 'non-controversial' (such as using '*' to mean multiply and
> 'curly braces' for essential grouping) this would seem to be a very mild
> insanity.

If it were merely equivalent to some expansion of this construct to
the rest of the language, that'd be true. It isn't.


-- 
Text by me above is hereby placed in the public domain

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

Re: ES3.1 Draft: 11 June 2008 version available

[Mark Miller]

On Fri, Jun 13, 2008 at 11:20 AM, Lars Hansen <[EMAIL PROTECTED]> wrote:
>> What
>> other "with" do people imagine is compatible with strict
>> mode? I must have missed something.
>
> The one in ES3.  What makes it not compatible with strict mode?

Doesn't it make static scope analysis impossible?


-- 
Text by me above is hereby placed in the public domain

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

Re: ES3.1 Draft: 11 June 2008 version available

[Mike Cowlishaw]

> Regarding whether there's a compelling reason to ban "with", what
> about the issue that "with" is an insanely confusing construct?

Compared to many other notations that language standards committees 
consider 'non-controversial' (such as using '*' to mean multiply and 
'curly braces' for essential grouping) this would seem to be a very mild 
insanity.

Mike





Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU






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

RE: ES3.1 Draft: 11 June 2008 version available

[Lars Hansen]

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Mark S. Miller
> Sent: 13. juni 2008 19:30
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; es4-discuss@mozilla.org
> Subject: Re: ES3.1 Draft: 11 June 2008 version available
> 
> On Fri, Jun 13, 2008 at 10:21 AM, Brendan Eich 
> <[EMAIL PROTECTED]> 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.
> 
> I'm confused. Aren't we talking about "reformed with"? 

Dead for a long time, now.

> What 
> other "with" do people imagine is compatible with strict 
> mode? I must have missed something.

The one in ES3.  What makes it not compatible with strict mode?

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

Re: ES3.1 Draft: 11 June 2008 version available

[Mark S. Miller]

On Fri, Jun 13, 2008 at 10:21 AM, Brendan Eich <[EMAIL PROTECTED]> 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.

I'm confused. Aren't we talking about "reformed with"? What other
"with" do people imagine is compatible with strict mode? I must have
missed something.


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

Re: ES3.1 Draft: 11 June 2008 version available

[Brendan Eich]

On Jun 13, 2008, at 10:11 AM, Mark S. Miller wrote:

> On Thu, Jun 12, 2008 at 9:45 AM, Sam Ruby <[EMAIL PROTECTED]> wrote:
>>> 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).
>
>
> Regarding whether there's a compelling reason to ban "with", what
> about the issue that "with" is an insanely confusing construct?

The horse has left the barn.


> On the spreadsheet, how much red was accumulated on "strict with"?

"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.


> IIRC, it was a lot. Does anyone think "with" is a valuable construct?
> Why? Anyone care to post a defense of "with"?

There's no point tilting at windmills. "with" is absolutely required  
for web compatibility, and it won't go away for a long, long time --  
if ever. It's insanely popular. It's not only common in extant or  
"legacy" JS, new uses crop up all the time.

You might hope to cause "with" to go away by forbidding it in a new,  
optional ES3.1 mode, but the chances of that seem at least as small  
as the chances that "with" popularity will simply make people avoid  
such a strict mode.

/be

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

Re: ES3.1 Draft: 11 June 2008 version available

[Mark S. Miller]

On Thu, Jun 12, 2008 at 9:45 AM, Sam Ruby <[EMAIL PROTECTED]> wrote:
>> 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).


Regarding whether there's a compelling reason to ban "with", what
about the issue that "with" is an insanely confusing construct?

On the spreadsheet, how much red was accumulated on "strict with"?
IIRC, it was a lot. Does anyone think "with" is a valuable construct?
Why? Anyone care to post a defense of "with"?

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

RE: ES3.1 Draft: 11 June 2008 version available

[Lars Hansen]

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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf 
> Of Sam Ruby
> Sent: 12. juni 2008 18:46
> To: Lars Hansen
> Cc: [EMAIL PROTECTED]; es4-discuss@mozilla.org
> 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
> 
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: ES3.1 Draft: 11 June 2008 version available

[Maciej Stachowiak]

On Jun 12, 2008, at 9:45 AM, Sam Ruby wrote:

> 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?

Having ES3.1 strict mode forbid features that ES4 strict mode does not  
(but which are in both languages) feels like breaking the subset  
relationship to me. The reason is that program that is purely ES3 but  
has the strict mode pragma added could then be legal in one language  
but not the other, which seems problematic.

To the extent that strict mode limits ES3-with-pragma programs, I  
think it should impose the same limits in ES3.1 and ES4.

Regards,
Maciej

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

Re: ES3.1 Draft: 11 June 2008 version available

[Sam Ruby]

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
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: ES3.1 Draft: 11 June 2008 version available

[André Rømcke]

Hi, and thanks for any work on making ES3 better while we wait for ES4!


One thing I miss form the targeted additions part of the spec is:
function.bindEvent aka function.bindEventListener

The difference from function.bind is that binded arguments are appended
after instead of before the arguments when called.

Example code for function.bind and function.bindEvent (where arguments is
a true array):


function.bind = function()
{
// Binds arguments to a function, so when you call the returned
wrapper function,
// arguments are intact and arguments passed to the wrapper function
is appended.
// first argument is 'this' and the rest is arguments
var args = arguments, __fn = this, __object = args.shift();
return function(){ return __fn.apply(__object, args.concat(arguments))};
};

function.bindEvent = function()
{
// Same as bind, but prepends the arguments to the wrapper function
var args = arguments, __fn = this, __object = args.shift();
return function(){ return __fn.apply(__object, arguments.concat(args))};
};



http://wiki.ecmascript.org/doku.php?id=es3.1:targeted_additions_to_array_string_object_date

On Thu, June 12, 2008 2:01 am, Pratap Lakshman (VJ#SDK) wrote:
> 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. Revision history is at the end of the document.
>
> pratap
>


-- 
Best Regards / Med vennlig hilsen
André Rømcke
System consultant & eZ Labs developer
eZ Systems Nordic
[EMAIL PROTECTED] | +47 21 53 69 13 | www.ez.no

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

RE: ES3.1 Draft: 11 June 2008 version available

[Lars Hansen]

Attaching comments.
 
In general this looks pretty clean.  (Some obvious missing parts
excepted.)  Of the things that do not look clean I want to single out
three worries specifically: That your strict mode is overreaching, that
too much (any!) emphasis is placed on catering to a non-existent "secure
subset" language, and that strict compatibility has not been maintained
with JS1.6/1.7/1.8 in the methods incorporated from those
specifications.  See the comments for details.  Also, there are numerous
occasions where the proposed language is incompatible with Proposed ES4,
so we have work to do to reconcile them.
 
--lars




From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Pratap Lakshman
(VJ#SDK)
Sent: 12. juni 2008 02:02
To: [EMAIL PROTECTED]
Cc: es4-discuss@mozilla.org
    Subject: ES3.1 Draft: 11 June 2008 version available 



I have uploaded to the wiki (link
<http://wiki.ecmascript.org/doku.php?id=es3.1:es3.1_proposal_working_dra
ft> , 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. Revision history is at the end of the
document.

 

pratap

p1.  "... some aspects of the language were defined to operate by
non-strict rules that are quite error prone. For backwards
compatibility, this "non - strict mode" remains the default. But a
scipt can now explicitly declare that it is in "strict mode", which
should make programming more robust for both professionals and
non-professionals."

Editorializing of this sort ("..are quite error prone.") is
inappropriate in a language standard.  It would be better simply to
note that the new strict mode catches more errors and that this
benefits large programs in particular.



p2.  The inserted reference to the Scheme report appears to be
gratuitous, as Scheme is not mentioned elsewhere in this document
(notably not in the preceding paragraph that mentions Java and Self).
Also, if you're going to mention Scheme then it would be better to
reference the last report (R6RS) or the IEEE standard (based on R4RS).


p2.  4.2#2 The deletion of "is an" to be replaced by "a" makes the
sentence grammatically incorrect.


p2.  4.2#2 (and throughout the document) Merriam-Webster's Collegiate
insists on "writable" and not "writeable".  But of course that book
documents US English, and as a non-native speaker of English I'm not
on firm ground here, so I would encourage the input of others.


p2.  4.2#4 The change in wording brings about a change in meaning that
is not obviously desirable, since the original wording allows more
implementation techniques than the new wording.


p3.  4.2.1#1 Inconsistent typography.  If you look forward to eg 13.2,
the typesetting for the prototype property is bold monospace; here you
have non-bold monospace with quotation marks.  Nobody disputes (I
think) that the ES3 spec could be cleaned up in this regard, but I
feel that the change here is just making matters worse.  Whatever you
do, using both monospace and quotes is inappropriate IMO.


p3.  4.2.1#2 This change does not clarify -- the new language is no
less confusing than the old -- and should be reverted.  (Furthermore,
the reference is not implicit, but the old spec got that wrong too.)


p4.  4.2.2 Again, editorializing ("error-prone behaviours") is
inappropriate for a language specification.


p5.  4.3.15.  No, you can't get rid of wrappers in strict mode (it
would violate the ES3.1 - ES4 subset relationship, for one thing).


p5.  4.3.24.  Wording: note that all the preceding paragraphs use
"instance of the built-in X object" not "X constructor".  Suggest you
follow that here.  Semantics: the notion of "primitive function"
appears nowhere else in the document that I can find and should
probably not be introduced here.  Conceivably it could be used to
explain the behavior of Function.prototype.toString on host and native
functions, but as those concepts are already present in ES3 they would
be the better choice.


p8.  5.1.4.  Disabling semicolon insertion in strict mode breaks the
ES3.1 - ES4 subset relationship.


p10.  5.2.  Though this algorithm notation is an improvement over what
ES3 uses, I question whether it's reasonable to introduce it without
changing all the algorithm descriptions, something I expect you will
not do.  IMO you should remove this, and new algorithms should be
described using the same notation as algorithms carried over from ES3.


p13.  7.2, 7.3.  LS is U+2028 and PS is U+2029, not the values shown
here.  Also, making LS and PS change status from line separator to
whitespace appears to be a gratuitous change.  Also, ZWSP is a format
control character in the

ES3.1 Draft: 11 June 2008 version available

[Pratap Lakshman (VJ#SDK)]

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. Revision history is at the end of the document.

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