Re: Forwards-compatible syntax proposal

[Waldemar Horwat]

I've had a request to repeat the example I showed at the meeting, so here's one:

{
  if (false) {
// Say we're introducing a new cast syntax '() '
var y = (int)/fo+/.exec("abcfoo");
  }
  push_the_button = false;
  {
z = y/x;
  }
}

In ECMAScript parsing and lexing are interleaved.  There is no way to tell 
without correctly parsing a piece of code whether / starts a regexp or is a 
division.  In the above example the regexp was meant to be /fo+/, but the 
syntax error recovery code will instead think that /.exec...y/x is an extended 
(multiline) regexp, missing the crucial closing brace of the block and the 
push_the_button = false statement.  Many other syntax errors can lead to this 
kind of lexer misalignment, hence it is impossible to isolate a syntax error to 
the first inner block above (or any other similar syntactic construct), despite 
the fact that it never executes due to the if (false).  You can make guesses 
based on indentation and such but guesses don't belong in a standard.

Waldemar


Waldemar Horwat wrote:
> This wouldn't work.  Without syntactically distinguishing a / that is a 
> division from a / that starts a regexp, there is no way to find the end 
> of the block.  To make this distinction you need to be able to parse the 
> contents of the block without errors.
> 
> To complicate matters further, various language extension proposals, 
> ranging from ES3.1 to various ES4 extensions, muck with the regexp syntax.
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: early reporting of malformed regex literals

[Waldemar Horwat]

Allen Wirfs-Brock wrote:
> In your comments on the June 11, ES3.1 draft you said:
> 
> p22 7.8.  Unacceptable change: The requirement to signal regular
> 
> expression syntax errors at scanning time breaks existing programs.
> (The justification ("since the arguments are the same every tine[sic],
> ..." appears to have no bearing on that and should be removed in any
> case.)
> 
> If the existing browser implementations don’t do this, would you agree 
> it would be better to simply eliminate the scanning time option?
> 
> Presumably, it would be acceptable to require early report in an opt-in 
> “strict mode”

If you intend to allow unescaped slashes inside regular expression literals, 
then you must report at least some regular expression syntax errors early.  
There's no way to continue parsing the rest of the program if you don't because 
you don't know where the regular expression literal ends.

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

Re: Newly revised Section 10 for ES3.1.

[Maciej Stachowiak]

On Jul 9, 2008, at 5:16 PM, Allen Wirfs-Brock wrote:



Const and function declarations within blocks must be uniquely  
named, such a declaration may not over-write a preceding declaration  
in the same block and an attempt to do so is a syntax error.  Such  
declarations, of course, shadow any like named declarations in  
enclosing scopes. Since consts and function declarations in blocks  
are new, this is a new semantics.


Although the standard does not allow block-level function  
declarations, the following will parse and give identical results in  
all four of the major browsers (it will alert "2"):



function g() {
if (true) {
function f() { alert("1"); }
function f() { alert("2"); }
}
f();
}
g();


This example will interoperably alert "1":


function g() {
if (true) {
function f() { alert("1"); }
}
f();
}
g();


As I understand it, your proposal would make the first example a  
syntax error and the second a runtime error (unless a global function  
named f is defined).


I know from experience that sites do accidentally depend on the  
intersection of the different IE and Firefox extensions for block- 
level function declarations (and the Safari and Opera attempts to  
emulate them). Do you have evidence that leads you to conclude that  
your proposed behavior is compatible with the Web? I am almost certain  
it is not.



Regards,
Maciej

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

Re: Newly revised Section 10 for ES3.1.

[Mike Shaver]

2008/7/9 Maciej Stachowiak <[EMAIL PROTECTED]>:
> Although the standard does not allow block-level function declarations

I'd understood that, while ES3 didn't specify such declarations, it
was not a violation of the standard to have them.  I agree with your
assessment of the compatibility impact, certainly.

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

Re: Newly revised Section 10 for ES3.1.

[Garrett Smith]

2008/7/9 Allen Wirfs-Brock <[EMAIL PROTECTED]>:
> I've just finished reworking section 10 to better accommodate block scoped
> function declarations and const statements.  In the course of this I had to
> make various decisions about the semantics. The primary purpose of this
> message is to provide visibility to those decisions and to get feedback on
> them.
>
>
>
> In introducing const statements and block scoped function declaration I
> tried to apply two over-riding principles:
>
> 1) Anything that is valid to do in ES3 continues to have the exact same
> semantics.
>
> 2) Anything thing that is new (or non-standard) and would not be valid in
> ES3 should have a semantics that is rational and consistent with a future
> introduction of block scoped Let variable bindings
>
>

A FunctionDeclaration in a block is not valid in ES3, so apparently
that is the reason for your note.

>
> Here are the results:
>
> All var declarations continue to be hoisted to "top-level" execution
> context. Vars never have block level scope or extent.
>
> ("top-level" mean the global code, eval code, or the top-level of a
> function.
>

This sentence is confusing. eval code is not necessarily global.

Reading further down, it seems that you mean to define "top-level" as
a new term for what we already know to mean [[Scope]] and then to
define a block scope term. It seems that you are aiming to
differentiate between function scope and a new type of "block" scope.

If my assumption is correct, then creating a new type of "block" scope
does not necessitate changing the term [[Scope]] to "top level".
[[Scope]] can still be [[Scope]] and block scope can be called
whatever you like ([[Block]], [[BlockScope]], et c)

Does this sound reasonable?

>
>
> Function declarations and const declarations are processed in parallel
> within a lexical contour (top-level or block). Neither has precedence over
>  the other, unlike the manner in which function declarations take precedence
> over formal parameters in ES3.
>
>
>
> A "top-level" function declaration over-writes any like-named formal
> parameters or preceding like-named function declarations.  This is an ES3
> semantics.
>

The global object cannot have parameters, so I should probably assume
that top-level means the same thing as [[Scope]] in ES3.

When you use a made-up word like "over-writes" it is unclear. It could
mean any of:

1) replaces the value
2) replaces the value and attributes
3) shadows a property in the scope chain (some do use the term
"override" in this way)

It is not clear what you mean.

> "Top-level" function declarations are writable.  Subsequent declarations or
> assignments may change their value. This is an ES3 semantics.
>

I'm not sure how you understand it, but let me explain how I
understand it, and maybe you'll see why what you've written is
confusing to me.

A FunctionDeclaration creates a property on the Variable object (or
replaces the value and attributes if it it already exists).

To quote the relevant part of the spec:

| 10.1.3 Variable Instantiation
|
|  Every execution context has associated with it a variable object.
| Variables and functions declared in the source text are added as
| properties of the variable object. For function code, parameters
| are added as properties of the variable object.

http://bclary.com/2004/11/07/#a-10.1.3


[snip]

>
> Within in a block, function declarations are read-only bindings. Since
> declarations in blocks are new, this is a new semantics.

IOW, a FunctionDeclaration creates a property of the BlockScope with
the attributes {ReadOnly, DontDelete}

>

> In the course of this, I noticed a number of conditions that plausibly might
> be restricted in the cautious subset, but currently aren't  specified as
> such:
>
> ·Illegal for a function to have duplicately named formal parameters
>

Is this a problem in ES3?

> ·Illegal for a function to contain a top level function declaration
> with a function name that is the same as a formal parameter.
>
> ·Illegal to have multiple top level function declarations for the
> same function name
>
> ·Illegal to have a function declaration with the same name as var
> declaration.
>
> ·Illegal for a function to contain a var declaration with the same
> name as a formal parameter.
>
> ·Illegal to assign to a top-level function name.
>

Five sensible suggestions, but they would be incompatible with ES3.0
(see quote above).

[snip]

> 10.1.6.1Usage Subset cautious Restrictions
>
> For functions defined within an execution subset restricted to the cautious
> subset, the activation object is only initialized with an "arguments"
> property if the function mentions "arguments" freely in its body. In which
> case the "arguments" property is initialized with attributes {[[Writable]]:
> false, [[Enumerable]]: false, [[Flexible]]: false}.
>

That would be incompatible with ES3. Arguments is not ReadOnly (or
"Writable:false"). (Doesn't see

Re: Newly revised Section 10 for ES3.1.

[Mark S. Miller]

On Wed, Jul 9, 2008 at 6:47 PM, Mike Shaver <[EMAIL PROTECTED]> wrote:

> 2008/7/9 Maciej Stachowiak <[EMAIL PROTECTED]>:
> > Although the standard does not allow block-level function declarations
>
> I'd understood that, while ES3 didn't specify such declarations, it
> was not a violation of the standard to have them.  I agree with your
> assessment of the compatibility impact, certainly.
>

I believe the prohibition is in the ES3 syntax definition.

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

Re: Newly revised Section 10 for ES3.1.

[Mark S. Miller]

Hi Maciej, IIUC, these examples work the same in Allen's proposal as the do
in ES4. If this does break the web, doesn't ES4 have exactly the same
problem?


On Wed, Jul 9, 2008 at 6:33 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:

>
> On Jul 9, 2008, at 5:16 PM, Allen Wirfs-Brock wrote:
>
>
> Const and function declarations within blocks must be uniquely named, such
> a declaration may not over-write a preceding declaration in the same block
> and an attempt to do so is a syntax error.  Such declarations, of course,
> shadow any like named declarations in enclosing scopes. Since consts and
> function declarations in blocks are new, this is a new semantics.
>
>
> Although the standard does not allow block-level function declarations, the
> following will parse and give identical results in all four of the major
> browsers (it will alert "2"):
>
> 
> function g() {
> if (true) {
> function f() { alert("1"); }
> function f() { alert("2"); }
> }
> f();
> }
> g();
> 
>
> This example will interoperably alert "1":
>
> 
> function g() {
> if (true) {
> function f() { alert("1"); }
> }
> f();
> }
> g();
> 
>
> As I understand it, your proposal would make the first example a syntax
> error and the second a runtime error (unless a global function named f is
> defined).
>
> I know from experience that sites do accidentally depend on the
> intersection of the different IE and Firefox extensions for block-level
> function declarations (and the Safari and Opera attempts to emulate them).
> Do you have evidence that leads you to conclude that your proposed behavior
> is compatible with the Web? I am almost certain it is not.
>
>
> Regards,
> Maciej
>
>


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

Re: Newly revised Section 10 for ES3.1.

[Brendan Eich]

On Jul 9, 2008, at 6:54 PM, Mark S. Miller wrote:

> On Wed, Jul 9, 2008 at 6:47 PM, Mike Shaver <[EMAIL PROTECTED]>  
> wrote:
> 2008/7/9 Maciej Stachowiak <[EMAIL PROTECTED]>:
> > > Although the standard does not allow block-level function  
> declarations
>
> > I'd understood that, while ES3 didn't specify such declarations, it
> > was not a violation of the standard to have them.  I agree with your
> > assessment of the compatibility impact, certainly.
>
> I believe the prohibition is in the ES3 syntax definition.

ES3 chapter 16:

An implementation shall report all errors as specified, except for  
the following:
• An implementation may extend program and regular expression syntax.  
To permit this, all operations (such as
calling eval, using a regular expression literal, or using the  
Function or RegExp constructor) that are allowed
to throw SyntaxError are permitted to exhibit implementation-defined  
behaviour instead of throwing SyntaxError
when they encounter an implementation-defined extension to the  
program or regular expression syntax.

As Maciej notes, all four browsers extend syntax to support functions  
in sub-statement contexts. There's no prohibition given the chapter  
16 language allowing such extensions. Is ES3.1 specifying  
"reality" (intersection semantics), or something not in the  
intersection or union of existing browsers' syntax and semantics,  
that is restrictive and therefore not compatible without a similar  
allowance for extensions?

Chapter 16 is important to carry forward in any 3.1 or 4 successor  
edition.

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

Re: Newly revised Section 10 for ES3.1.

[Brendan Eich]

On Jul 9, 2008, at 6:58 PM, Mark S. Miller wrote:

> Hi Maciej, IIUC, these examples work the same in Allen's proposal  
> as the do in ES4. If this does break the web, doesn't ES4 have  
> exactly the same problem?

The idea for ES4 was to change the meaning of function sub-statements  
only under opt-in versioning. Implementations would do whatever they  
do today without an explicit type="application/ecmascript;version=4"  
or equivalent "application/javascript;version=2" on the script tag.

/be


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

Re: Newly revised Section 10 for ES3.1.

[Mark S. Miller]

On Wed, Jul 9, 2008 at 7:02 PM, Brendan Eich <[EMAIL PROTECTED]> wrote:

> On Jul 9, 2008, at 6:58 PM, Mark S. Miller wrote:
>
>  Hi Maciej, IIUC, these examples work the same in Allen's proposal as the
>> do in ES4. If this does break the web, doesn't ES4 have exactly the same
>> problem?
>>
>
> The idea for ES4 was to change the meaning of function sub-statements only
> under opt-in versioning. Implementations would do whatever they do today
> without an explicit type="application/ecmascript;version=4" or equivalent
> "application/javascript;version=2" on the script tag.
>


I had not understood that. I knew that new keywords were switched by the ES4
opt-in, and I have been following what ES4 switches based on strictness, but
I probably haven't paid enough attention to ES4 opt-in. Besides keywords,
what other elements of ES4 are switched on opt-in rather than strictness?
Are all four combinations of opt-in vs strictness possible? Is opt-in per
execution context (script) or per global object (frame)? A link to the
relevant docs is an adequate answer. Thanks.


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

Re: es3.1:relationship_with_the_es4_specification

[Peter Michaux]

On Sun, Jul 6, 2008 at 3:35 PM, Brendan Eich <[EMAIL PROTECTED]> wrote:
> On Jul 6, 2008, at 3:06 PM, Peter Michaux wrote:
>
>> Has there been any resolution about how the es3.1 specification will
>> be officially named?
>
> Yes, Ecma TC39 talked about this and the issue was not forcing a version
> step for marketing reasons, rather the lack of dotted edition numbers in
> Ecma standards -- which the TC39 Chair and Ecma Secretary-General agreed
> could be added easily. So the ES3.1 work is aiming to create ECMA-262
> Edition 3.1, and ES4 the 4th Edition.

Well that was mighty accommodating of them.

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

Re: proper tail calls still out of es4?

[Peter Michaux]

Hi Brendan,

Thanks for the reply...

On Sun, Jul 6, 2008 at 3:52 PM, Brendan Eich <[EMAIL PROTECTED]> wrote:

> My belief is that if proper tail calls are to make a come-back, it will be
> through implementors leading the way. As discussed in the linked documents
> cited above, support by popular implementations on the web would tend to
> force a de-facto standard. This might not be evident by the time ES4 is
> standardized, but it could be folded into a successor standard.

How could one go about campaigning for Spidermonkey to lead the way by
including proper tail calls?

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

RE: Newly revised Section 10 for ES3.1.

[Allen Wirfs-Brock]

Yes, but

function g() {
if (true) {
function f() { alert("1"); }
   }
   Else {
function f() { alert("2"); }
}
f();
}
g();


doesn't yield consistent results across browsers. Even if we can craft a 
specification that just captured those aspects of block nest function 
declarations that are identical in the 4 principal browsers would It's not 
clear that anybody would  be very happy with the result. (For example, a 
function of a given name can occurs in at most one conditionally executed 
block). Arguably, one "advantage" of my proposal is that it equally breaks all 
the existing implementations of block nested function declarations.

From: Maciej Stachowiak [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 09, 2008 6:34 PM
To: Allen Wirfs-Brock
Cc: [EMAIL PROTECTED]; es4-discuss@mozilla.org; Mark S. Miller; Herman Venter; 
Pratap Lakshman (VJ#SDK); Douglas Crockford
Subject: Re: Newly revised Section 10 for ES3.1.


On Jul 9, 2008, at 5:16 PM, Allen Wirfs-Brock wrote:



Const and function declarations within blocks must be uniquely named, such a 
declaration may not over-write a preceding declaration in the same block and an 
attempt to do so is a syntax error.  Such declarations, of course, shadow any 
like named declarations in enclosing scopes. Since consts and function 
declarations in blocks are new, this is a new semantics.

Although the standard does not allow block-level function declarations, the 
following will parse and give identical results in all four of the major 
browsers (it will alert "2"):


function g() {
if (true) {
function f() { alert("1"); }
function f() { alert("2"); }
}
f();
}
g();


This example will interoperably alert "1":


function g() {
if (true) {
function f() { alert("1"); }
}
f();
}
g();


As I understand it, your proposal would make the first example a syntax error 
and the second a runtime error (unless a global function named f is defined).

I know from experience that sites do accidentally depend on the intersection of 
the different IE and Firefox extensions for block-level function declarations 
(and the Safari and Opera attempts to emulate them). Do you have evidence that 
leads you to conclude that your proposed behavior is compatible with the Web? I 
am almost certain it is not.


Regards,
Maciej

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

Re: Newly revised Section 10 for ES3.1.

[Mike Shaver]

2008/7/10 Allen Wirfs-Brock <[EMAIL PROTECTED]>:
> Even if we can craft a
> specification that just captured those aspects of block nest function
> declarations that are identical in the 4 principal browsers would It's not
> clear that anybody would  be very happy with the result.

It seems like that would be at least as much worth trying as is "make
something that's actively incompatible with all 4 browsers", no?

> Arguably, one "advantage" of my proposal is that it equally breaks
> all the existing implementations of block nested function declarations.

I can only presume that you're joking here.

FWIW, this sort of thing is a reason that I'm pretty concerned about
ES3.1 getting into an advanced specification state without the benefit
of any in-browser implementation.

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

RE: Newly revised Section 10 for ES3.1.

[Allen Wirfs-Brock]

I completely agree, chapter 16 needs to carry forward.  We don't want to forbid 
implementations from experimenting with future extensions.

When there has been broad agreement across major implements on an extension 
(including the full semantics), I think it makes sense to standardize that 
consensus. If there isn't such agreement, I'm not so sure it makes sense to 
only standardize the compatible intersection of major implementations as that 
may not be a useful subset of functionality.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brendan Eich
Sent: Wednesday, July 09, 2008 7:00 PM
To: Mark S. Miller
Cc: [EMAIL PROTECTED]; es4-discuss@mozilla.org; Herman Venter
Subject: Re: Newly revised Section 10 for ES3.1.

On Jul 9, 2008, at 6:54 PM, Mark S. Miller wrote:

> On Wed, Jul 9, 2008 at 6:47 PM, Mike Shaver <[EMAIL PROTECTED]>
> wrote:
> 2008/7/9 Maciej Stachowiak <[EMAIL PROTECTED]>:
> > > Although the standard does not allow block-level function
> declarations
>
> > I'd understood that, while ES3 didn't specify such declarations, it
> > was not a violation of the standard to have them.  I agree with your
> > assessment of the compatibility impact, certainly.
>
> I believe the prohibition is in the ES3 syntax definition.

ES3 chapter 16:

An implementation shall report all errors as specified, except for
the following:
* An implementation may extend program and regular expression syntax.
To permit this, all operations (such as
calling eval, using a regular expression literal, or using the
Function or RegExp constructor) that are allowed
to throw SyntaxError are permitted to exhibit implementation-defined
behaviour instead of throwing SyntaxError
when they encounter an implementation-defined extension to the
program or regular expression syntax.

As Maciej notes, all four browsers extend syntax to support functions
in sub-statement contexts. There's no prohibition given the chapter
16 language allowing such extensions. Is ES3.1 specifying
"reality" (intersection semantics), or something not in the
intersection or union of existing browsers' syntax and semantics,
that is restrictive and therefore not compatible without a similar
allowance for extensions?

Chapter 16 is important to carry forward in any 3.1 or 4 successor
edition.

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

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

RE: Newly revised Section 10 for ES3.1.

[Allen Wirfs-Brock]

I'm also confused about this.  My understanding was, other than perhaps some of 
the details I was specifically looking for feedback on, that what I specified 
was generally what ES4 was planning on doing.

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark S. Miller
Sent: Wednesday, July 09, 2008 7:13 PM
To: Brendan Eich
Cc: Herman Venter; Douglas Crockford; [EMAIL PROTECTED]; 
es4-discuss@mozilla.org; Pratap Lakshman (VJ#SDK)
Subject: Re: Newly revised Section 10 for ES3.1.

On Wed, Jul 9, 2008 at 7:02 PM, Brendan Eich <[EMAIL PROTECTED]> wrote:
On Jul 9, 2008, at 6:58 PM, Mark S. Miller wrote:
Hi Maciej, IIUC, these examples work the same in Allen's proposal as the do in 
ES4. If this does break the web, doesn't ES4 have exactly the same problem?

The idea for ES4 was to change the meaning of function sub-statements only 
under opt-in versioning. Implementations would do whatever they do today 
without an explicit type="application/ecmascript;version=4" or equivalent 
"application/javascript;version=2" on the script tag.


I had not understood that. I knew that new keywords were switched by the ES4 
opt-in, and I have been following what ES4 switches based on strictness, but I 
probably haven't paid enough attention to ES4 opt-in. Besides keywords, what 
other elements of ES4 are switched on opt-in rather than strictness? Are all 
four combinations of opt-in vs strictness possible? Is opt-in per execution 
context (script) or per global object (frame)? A link to the relevant docs is 
an adequate answer. Thanks.


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

Re: Newly revised Section 10 for ES3.1.

[Brendan Eich]

On Jul 9, 2008, at 10:05 PM, Allen Wirfs-Brock wrote:
I’m also confused about this.  My understanding was, other than  
perhaps some of the details I was specifically looking for feedback  
on, that what I specified was generally what ES4 was planning on  
doing.




See my reply to Mark citing

http://wiki.ecmascript.org/doku.php? 
id=meetings:minutes_mar_27_2008#technical_notes


"[W]hat ES4 was planning on doing" needs to be qualified with "under  
the default version" of JS, or under opt-in versioning. Again since  
default versions get differing function statement semantics depending  
on browser, unless all browsers can afford to break existing browser- 
specific content, the change to unify on proposed ES4 semantics may  
need to be under opt-in version selection only.


If some browsers implemented in a way that happens to work for most  
browser-specific content (it's hard to be sure), then perhaps those  
implementations could just make the change. But for cross-browser  
portability, web scripts would want to select the explicit version  
that guarantees the new semantics (and syntax, for that matter) in  
all browsers that support that version.


/be

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

RE: Newly revised Section 10 for ES3.1.

[Allen Wirfs-Brock]

There was two parts to may message, an informal overview of the proposed 
semantics and the excerpt from the actual "formal" (and I use that term 
advisedly) specification of the semantics.  I was using the term "top-level" in 
the informal part of the message to refer to code that wasn't in a nested 
block.  It is not intended to be new formal terminology of the specification.  
It has nothing to do with the [[Scope]] property.  I do introduce some new 
formal terminology but it is all in the specification excerpt, not in the 
informal overview.  [[Scope]] is simply the internal property that is used to 
capture the lexical environment (the scope chain) that is active when a 
function object is created.

What I do introduce is a new kind of execution context for lexical blocks and a 
new kind of activation object that is associated with lexical block execution 
contexts.

You confusion about the meaning of my informal language reasonably points out 
the weakness of informal descriptions. Please read the actual rewrite of 
section 10 and see if you also find it confusing or ambiguous. If so, that's 
important and something I will try to fix.

Regarding, the "cautious subset" restrictions.  By design, they are 
incompatible with ES3.  The cautious subset (or the similar but not yet 
identical ES4 strict mode" is an Opt-in subset of the ES3.1 language that among 
other things allows a programmer to request that certain problematic ES3 
constructs become illegal and generate errors. Every valid proposed ES3.1 
cautious subset program is also a valid program in the full language.  However, 
every valid program in the full language is not necessarily a valid cautious 
subset program.

-Original Message-
From: Garrett Smith [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 09, 2008 6:48 PM
To: Allen Wirfs-Brock
Cc: es4-discuss@mozilla.org; Mark S. Miller; Herman Venter; Pratap Lakshman 
(VJ#SDK); Douglas Crockford
Subject: Re: Newly revised Section 10 for ES3.1.

2008/7/9 Allen Wirfs-Brock <[EMAIL PROTECTED]>:
> I've just finished reworking section 10 to better accommodate block scoped
> function declarations and const statements.  In the course of this I had to
> make various decisions about the semantics. The primary purpose of this
> message is to provide visibility to those decisions and to get feedback on
> them.
>
>
>
> In introducing const statements and block scoped function declaration I
> tried to apply two over-riding principles:
>
> 1) Anything that is valid to do in ES3 continues to have the exact same
> semantics.
>
> 2) Anything thing that is new (or non-standard) and would not be valid in
> ES3 should have a semantics that is rational and consistent with a future
> introduction of block scoped Let variable bindings
>
>

A FunctionDeclaration in a block is not valid in ES3, so apparently
that is the reason for your note.

>
> Here are the results:
>
> All var declarations continue to be hoisted to "top-level" execution
> context. Vars never have block level scope or extent.
>
> ("top-level" mean the global code, eval code, or the top-level of a
> function.
>

This sentence is confusing. eval code is not necessarily global.

Reading further down, it seems that you mean to define "top-level" as
a new term for what we already know to mean [[Scope]] and then to
define a block scope term. It seems that you are aiming to
differentiate between function scope and a new type of "block" scope.

If my assumption is correct, then creating a new type of "block" scope
does not necessitate changing the term [[Scope]] to "top level".
[[Scope]] can still be [[Scope]] and block scope can be called
whatever you like ([[Block]], [[BlockScope]], et c)

Does this sound reasonable?

>
>
> Function declarations and const declarations are processed in parallel
> within a lexical contour (top-level or block). Neither has precedence over
>  the other, unlike the manner in which function declarations take precedence
> over formal parameters in ES3.
>
>
>
> A "top-level" function declaration over-writes any like-named formal
> parameters or preceding like-named function declarations.  This is an ES3
> semantics.
>

The global object cannot have parameters, so I should probably assume
that top-level means the same thing as [[Scope]] in ES3.

When you use a made-up word like "over-writes" it is unclear. It could
mean any of:

1) replaces the value
2) replaces the value and attributes
3) shadows a property in the scope chain (some do use the term
"override" in this way)

It is not clear what you mean.

> "Top-level" function declarations are writable.  Subsequent declarations or
> assignments may change their value. This is an ES3 semantics.
>

I'm not sure how you understand it, but let me explain how I
understand it, and maybe you'll see why what you've written is
confusing to me.

A FunctionDeclaration creates a property on the Variable object (or
replaces the value and attributes if it it already exists).

To quote the

Re: Newly revised Section 10 for ES3.1.

[Mark S. Miller]

On Wed, Jul 9, 2008 at 10:35 PM, Allen Wirfs-Brock <
[EMAIL PROTECTED]> wrote:

> Every valid proposed ES3.1 cautious subset program is also a valid program
> in the full language.


I don't think it works to restate the "fail stop subset" notion in terms of
validity. Rather, we can say that an ES3.1 cautious program that runs
without causing any cautiousness-induced failures will run the same way in
the full language. Put another way, Given an alleged ES3.1 cautious program,
it will

* be statically rejected
* cause a failure by violating a dynamic cautiousness restriction
* execute as it would in the full ES3.1 language.

For example, the following is a perfectly *valid* ES3.1 cautious function:

function isCautious() {
  function foo() {this;}
  try { foo(); } catch (e) { return true; }
  return false;
}

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

RE: Newly revised Section 10 for ES3.1.

[Allen Wirfs-Brock]

>> It seems like that would be at least as much worth trying as is "make
something that's actively incompatible with all 4 browsers", no?

I'd love to see a proposal

>> I can only presume that you're joking here.

Not really, if you have to change something it may be better to do it in a way 
that breaks all existing uses rather than just some of them.  It isn't obvious 
that either the FF or IE approach to function declarations in conditional 
blocks is "better" or more correct.  Arguments can be made on both design 
choices. In such a situation, the best solution may actually be to break both 
of them rather than breaking only one of them.  Particularly, if there is a 
strong argument that the new design is better than either of the existing ones.

>> FWIW, this sort of thing is a reason that I'm pretty concerned about
ES3.1 getting into an advanced specification state without the benefit
of any in-browser implementation.

You need to have an advance specification state before you can meaningfully 
test it in an implementation.

-Original Message-
From: Mike Shaver [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 09, 2008 9:49 PM
To: Allen Wirfs-Brock
Cc: Maciej Stachowiak; Herman Venter; Mark S. Miller; [EMAIL PROTECTED]; 
es4-discuss@mozilla.org
Subject: Re: Newly revised Section 10 for ES3.1.

2008/7/10 Allen Wirfs-Brock <[EMAIL PROTECTED]>:
> Even if we can craft a
> specification that just captured those aspects of block nest function
> declarations that are identical in the 4 principal browsers would It's not
> clear that anybody would  be very happy with the result.

It seems like that would be at least as much worth trying as is "make
something that's actively incompatible with all 4 browsers", no?

> Arguably, one "advantage" of my proposal is that it equally breaks
> all the existing implementations of block nested function declarations.

I can only presume that you're joking here.

FWIW, this sort of thing is a reason that I'm pretty concerned about
ES3.1 getting into an advanced specification state without the benefit
of any in-browser implementation.

Mike

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

RE: Newly revised Section 10 for ES3.1.

[Allen Wirfs-Brock]

This is currently stated in section 4.2.2 of the draft as:


With one exception, an ECMAScript program that is voluntarily limited to a 
usage subset  and which executes without error under the subset's restrictions 
will behave identically if executed without on any usage subset restrictions. 
The exception is any situation where the operation of such a program depends 
upon the actual occurrence and subsequent handling of additional error 
conditions that are part of the subset.


From: Mark S. Miller [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 09, 2008 10:48 PM
To: Allen Wirfs-Brock
Cc: Garrett Smith; es4-discuss@mozilla.org; Herman Venter; Pratap Lakshman 
(VJ#SDK); Douglas Crockford
Subject: Re: Newly revised Section 10 for ES3.1.

On Wed, Jul 9, 2008 at 10:35 PM, Allen Wirfs-Brock <[EMAIL 
PROTECTED]> wrote:
Every valid proposed ES3.1 cautious subset program is also a valid program in 
the full language.

I don't think it works to restate the "fail stop subset" notion in terms of 
validity. Rather, we can say that an ES3.1 cautious program that runs without 
causing any cautiousness-induced failures will run the same way in the full 
language. Put another way, Given an alleged ES3.1 cautious program, it will

* be statically rejected
* cause a failure by violating a dynamic cautiousness restriction
* execute as it would in the full ES3.1 language.

For example, the following is a perfectly *valid* ES3.1 cautious function:

function isCautious() {
  function foo() {this;}
  try { foo(); } catch (e) { return true; }
  return false;
}

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

Re: Newly revised Section 10 for ES3.1.

[Mark Miller]

2008/7/9 Allen Wirfs-Brock <[EMAIL PROTECTED]>:
> This is currently stated in section 4.2.2 of the draft as:
>
> With one exception, an ECMAScript program that is voluntarily limited to a
> usage subset  and which executes without error under the subset's
> restrictions will behave identically if executed without on any usage subset
> restrictions. The exception is any situation where the operation of such a
> program depends upon the actual occurrence and subsequent handling of
> additional error conditions that are part of the subset.

I like and agree with that text. My point exactly is your exception
above: a valid program may react to a subset-induced error condition.

ES4 folks,

What are the compatibility relationships between ES4 opt-in, ES4
opt-in strict, ES4 strict, and ES4? I think it's clear that ES4 opt-in
strict is a subset of ES4 opt-in. Are there any other subset
relationships among them? I hadn't realized till just now how large
the gulf might be between ES4 opt-in and ES4. Do opt-in and strict
define orthogonal switches? Can opt-in and non-opt-in programs
co-exist in the same frame (global object)? We all need to clarify
these issues.

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