Newly revised Section 10 for ES3.1.

Maciej Stachowiak mjs at
Thu Jul 10 00:02:02 PDT 2008

On Jul 9, 2008, at 10:01 PM, Allen Wirfs-Brock wrote:

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

Sure, but your proposal is actively incompatible with all the existing  
implementations, because real web content does in fact do things like  

if (someConditionThatIsAlwaysTrue) {
      function someFuncIThoughtWasConditionallyDeclared() {
          // some code

and then the content counts on the function declaration being hoisted.  
Your proposal breaks that. It would also in some cases cause parse  
errors on content that would currently parse in all the browsers,  
meaning that even a mistake in a function that never gets called would  
start causing the whole script to fail.

I do not know if it is possible to make a proposal that both is useful  
and doesn't break the Web, within the premises of ES3.1. But it seems  
to me that a proposal that is almost sure to break the Web would be  
unacceptable under the ES3.1 assumptions, and locking it into a spec  
without first doing some form of widespread testing seems like a  
totally broken process.

I do not believe that ECMA has the "two interoperable implementations"  
rule that the IETF and W3C have, but since ECMAScript is a standard of  
equal important to the Web, I think we should adopt this rule for any  
future edition of ECMAScript. Such a rule is needed precisely to avoid  
such casual breakage relative to Web reality. Can we make that a  
binding TC39 resolution?


> -----Original Message-----
> From: es4-discuss-bounces at [mailto:es4-discuss-bounces at 
> ] On Behalf Of Brendan Eich
> Sent: Wednesday, July 09, 2008 7:00 PM
> To: Mark S. Miller
> Cc: es3.x-discuss at; es4-discuss at; 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 <mike.shaver at>
>> wrote:
>> 2008/7/9 Maciej Stachowiak <mjs at>:
>>>> 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 at
> _______________________________________________
> Es3.x-discuss mailing list
> Es3.x-discuss at

More information about the Es4-discuss mailing list