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
this:
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?
Regards,
Maciej
>
>
> -----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
>
> _______________________________________________
> 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
