const formal parameters?

[Mark S. Miller-2]

As previously mentioned, we've decided to allow "const" variable
declarations into ES3.1 under the "parses on 3/4 browser rule"
(FF,Safari,Opera) since it also aids integrity. However, it's a bit
mysterious how to declare formal parameter variables to be const in a
way that'll parse on 3/4 browsers. Both Firefox and Safari reject

    function foo(x, const y) { return [x, y];}

as a syntax error. However, they both accept

    function foo(x, y) { var y; return [x, y];}

and they correctly do not  treat the "var x;" as shadowing the "x"
parameter variable. So I thought I'd try

    function foo(x, y) { const y; return [x, y];}

On FF 2.0.0.14 under squarefree this gives a "TypeError on line 1:
redeclaration of formal parameter y". On Safari it parses fine, but of
course that the const-ness is not yet enforced.  Would ES4 interpret
the above syntax as declaring the "y" parameter variable to be const?
If so, what immediate plans do FF and Opera have re this syntax? If
both expect this to parse soon, perhaps we should stretch our 3/4 rule
and permit it? If not, any other suggestions for declaring formal
parameter variables to be const in ES3.1?

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

[Brendan Eich-2]

On Jun 19, 2008, at 4:07 PM, Mark S. Miller wrote:

> As previously mentioned, we've decided to allow "const" variable
> declarations into ES3.1 under the "parses on 3/4 browser rule"
> (FF,Safari,Opera) since it also aids integrity.

It may parse, but if const turns into var, as in Opera, or is not  
block-scoped (Firefox and Safari), then no one can count on it until  
some future releases. This again makes me ask: what's the plan for  
getting "alpha" implementations of ES3.1 interoperating before the  
standard is pushed through Ecma to ISO?


> However, it's a bit
> mysterious how to declare formal parameter variables to be const in a
> way that'll parse on 3/4 browsers.

It's not mysterious, it is simply not possible.

> Both Firefox and Safari reject
>
>     function foo(x, const y) { return [x, y];}
>
> as a syntax error. However, they both accept
>
>     function foo(x, y) { var y; return [x, y];}
>
> and they correctly do not  treat the "var x;" as shadowing the "x"
> parameter variable. So I thought I'd try
>
>     function foo(x, y) { const y; return [x, y];}
>
> On FF 2.0.0.14 under squarefree this gives a "TypeError on line 1:
> redeclaration of formal parameter y". On Safari it parses fine, but of
> course that the const-ness is not yet enforced.  Would ES4 interpret
> the above syntax as declaring the "y" parameter variable to be const?

I don't know for sure, but it is plausible since we do not require  
initialization in the declaration, rather write-once. But does it  
matter? I think ES3.1 is way over the line of mission creep in trying  
to get const formal parameters wedged in. They do not parse in any  
browser implementations. 'const' forward compatibility is iffy to  
broken due to the different scope rules. It seems to me, and I'm  
writing this in order to help 3.1 get done and done well, that you  
really should just cut anything like const parameters now.


> If so, what immediate plans do FF and Opera have re this syntax? If
> both expect this to parse soon, perhaps we should stretch our 3/4 rule
> and permit it? If not, any other suggestions for declaring formal
> parameter variables to be const in ES3.1?

What good is the 3/4 browsers rule if it allows wildly divergent (or  
in Opera's case, mapping const to var, meaningless) semantics for  
const? Getting something to parse, but not behave as proposed (adding  
integrity), seems like a sure way to deliver secure-looking but  
insecure-behaving code to certain browsers.

/be

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

[Mark S. Miller-2]

On Thu, Jun 19, 2008 at 5:39 PM, Brendan Eich <brendan@...> wrote:
> On Jun 19, 2008, at 4:07 PM, Mark S. Miller wrote:
>
>> As previously mentioned, we've decided to allow "const" variable
>> declarations into ES3.1 under the "parses on 3/4 browser rule"
>> (FF,Safari,Opera) since it also aids integrity.
>
> It may parse, but if const turns into var, as in Opera, or is not
> block-scoped (Firefox and Safari), then no one can count on it until some
> future releases.

[out of order]
> What good is the 3/4 browsers rule if it allows wildly divergent (or in
> Opera's case, mapping const to var, meaningless) semantics for const?
> Getting something to parse, but not behave as proposed (adding integrity),
> seems like a sure way to deliver secure-looking but insecure-behaving code
> to certain browsers.

So long as it parses, that would allow code to version sniff and
adapt, with conditionals, to different execution environments. That's
why we're using the "parses on 3/4 browsers" criterion. (Thanks
Maciej, I think)


> This again makes me ask: what's the plan for getting
> "alpha" implementations of ES3.1 interoperating before the standard is
> pushed through Ecma to ISO?

I don't know if the ES3.1 WG has discussed how to get to ISO. I've
only participated in discussions re an Ecma std, for which we're
planning to leverage the ES4 RI. What would you suggest for ISO?


>> However, it's a bit
>> mysterious how to declare formal parameter variables to be const in a
>> way that'll parse on 3/4 browsers.
>
> It's not mysterious, it is simply not possible.

I was hoping that the

    function foo(x, y) { const y; return [x, y];}

syntax I suggested was close enough to possible. However, I just
verified that it doesn't parse on Opera 9.5 either, so I give up on
this one.


> I don't know for sure, but it is plausible since we do not require
> initialization in the declaration, rather write-once. But does it matter? I
> think ES3.1 is way over the line of mission creep in trying to get const
> formal parameters wedged in. They do not parse in any browser
> implementations. 'const' forward compatibility is iffy to broken due to the
> different scope rules. It seems to me, and I'm writing this in order to help
> 3.1 get done and done well, that you really should just cut anything like
> const parameters now.

I certainly appreciate the sentiment, and I agree on this case. It
just seems weird to be able to declare local variables const but not
be able to declare parameter variables const. Oh well, it's not the
weirdest thing that we've decided to live with.


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

[Brendan Eich-2]

On Jun 19, 2008, at 8:17 PM, Mark S. Miller wrote:

So long as it parses, that would allow code to version sniff and

adapt, with conditionals, to different execution environments. That's

why we're using the "parses on 3/4 browsers" criterion. (Thanks

Maciej, I think)

"Adapt" means "do without" on Opera, in this case. But IE is out already, so I guess the user-agent sniffing should put Opera in the same no-const branch that IE gets.

This again makes me ask: what's the plan for getting

"alpha" implementations of ES3.1 interoperating before the standard is

pushed through Ecma to ISO?

I don't know if the ES3.1 WG has discussed how to get to ISO. I've

only participated in discussions re an Ecma std, for which we're

planning to leverage the ES4 RI. What would you suggest for ISO?

Ecma specs go to ISO via the JTC1 fast-track process, mostly polishing and picking nits. The time to get implementor and user feedback is before Ecma stamps the standard as "done". This was obviously the case for ES1, and ES2 followed implementations adopting features such as do-while and switch. ES3 had some innovations beyond what implementations had already supported -- some of these did not work so well while others were ignored by vendors of already-shipped code.

I certainly appreciate the sentiment, and I agree on this case. It

just seems weird to be able to declare local variables const but not

be able to declare parameter variables const. Oh well, it's not the

weirdest thing that we've decided to live with.

const parameters are supported in ES4, FWIW.

/be

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

[Maciej Stachowiak]

On Jun 19, 2008, at 8:17 PM, Mark S. Miller wrote:

>
> So long as it parses, that would allow code to version sniff and
> adapt, with conditionals, to different execution environments. That's
> why we're using the "parses on 3/4 browsers" criterion. (Thanks
> Maciej, I think)

I think my only involvement in the 3/4 rule was asking what it  
actually meant. I'm not sure who deserves credit for originating it.

Regards,
Maciej

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