Arguments and formal parameters aliasing

Hello!

I just noticed an inconsistency between the ES3 spec and browsers that
I've not seen discussed before. At the moment I'm on my iBook, so
these are not the most recent browsers, but they include ie5.2m, ff2,
saf1.3 and op9.5.


    function fn(a, b, c, d, a, b, c, e){
        arguments[7]='e';
        b='g';
        return [
            'a: '+a+'  arg0: '+arguments[0],
            'b: '+b+'  arg1: '+arguments[1],
            'c: '+c+'  arg2: '+arguments[2],
            'd: '+d+'  arg3: '+arguments[3],
            'a: '+a+'  arg4: '+arguments[4],
            'b: '+b+'  arg5: '+arguments[5],
            'c: '+c+'  arg6: '+arguments[6],
            'e: '+e+'  arg7: '+arguments[7]]
                .join('\r\n');
}

fn('a','b','c','d','e','f');

Results from ff2, op5 and ie5.2m are:
    a: e  arg0: a
    b: g  arg1: b
    c: undefined  arg2: c
    d: d  arg3: d
    a: e  arg4: e
    b: g  arg5: g
    c: undefined  arg6: undefined
    e: undefined  arg7: e

Results from saf1.3 are:
    a: e  arg0: a
    b: g  arg1: b
    c: undefined  arg2: c
    d: d  arg3: d
    a: e  arg4: e
    b: g  arg5: f
    c: undefined  arg6: undefined
    e: undefined  arg7: e

I haven't been able to test this since I'm not on a windows machine,
but IIRC Chrome will alias e and arg7 but otherwise behave like
moz/op/ie. I also suspect that later saf versions than 1.3 will
correctly alias b with arg5.



The ES3 spec has the following to say about this:
~~~~<10.1.3 Variable Instantiation>~~~~
...
 •  For function code: for each formal parameter, as defined in the
FormalParameterList, create a property of the  variable object whose
name is the Identifier and whose attributes are determined by the type
of code. The values  of the parameters are supplied by the caller as
arguments to [[Call]]. If the caller supplies fewer parameter values
than there are formal parameters, the extra formal parameters have
value undefined. If two or more formal  parameters share the same
name, hence the same property, the corresponding property is given the
value that  was supplied for the last parameter with this name. If the
value of this last parameter was not supplied by the  caller, the
value of the corresponding property is undefined.
...
~~~~</>~~~~
In other words saying that two formal parameters with the same
identifier are the same variable, and that the last one in the
parameter list will be the one giving the variable a value.
~~~~<10.1.8 Arguments Object>~~~~
...
 •  For each non-negative integer, arg, less than the value of the
length property, a property is created with name  ToString(arg) and
property attributes { DontEnum }. The initial value of this property
is the value of the  corresponding actual parameter supplied by the
caller. The first actual parameter value corresponds to arg = 0,  the
second to arg = 1, and so on. In the case when arg is less than the
number of formal parameters for the  Function object, this property
shares its value with the corresponding property of the activation
object. This  means that changing this property changes the
corresponding property of the activation object and vice versa.
~~~~</>~~~~
And this says that each argument sent is aliased to the corresponding
formal parameter's variable. Given the behaviour of several parameters
with identical identifier earlier, and no exception being given for
this case, I can only read this as meaning that the browser
implementations go contrary to the ES3 spec regarding arg0, arg1 ,
arg2 and the a, b and c variables not being being aliased. It seems
the browser scripting engines only alias the last argument
corresponding to any given formal parameter identifier with the
corresponding variable, even though these are supposed to be the same
variable.


Something to address in ES3.1, given at least three, probably four
implementors disagree with the ES3 spec?
-- 
David "liorean" Andersson

liorean wrote:
[...]
> ~~~~<10.1.3 Variable Instantiation>~~~~
> [...] If two or more formal parameters share the same
> name, hence the same property, the corresponding property is given the
> value that was supplied for the last parameter with this name.

Can anyone explain what the original rationale was for this? To me it
seems like duplicate parameter names are an obvious programming error, and
it makes no sense from a language design point of view to allow them.

(Yes, I understand that they are disallowed in ES3.1 strict mode, and that
disallowing them in non-strict mode would break compatibility. I'm just
curious what was going through the minds of the ES1 standardizers.)

-- 
David-Sarah Hopwood

On Sep 27, 2008, at 8:14 PM, David-Sarah Hopwood wrote:

> liorean wrote:
> [...]
>> ~~~~<10.1.3 Variable Instantiation>~~~~
>> [...] If two or more formal parameters share the same
>> name, hence the same property, the corresponding property is given  
>> the
>> value that was supplied for the last parameter with this name.
>
> Can anyone explain what the original rationale was for this? To me it
> seems like duplicate parameter names are an obvious programming  
> error, and
> it makes no sense from a language design point of view to allow them.

I do not know. Shon Katzenberger of Microsoft may be the only person  
who can say. Duplicate formals were not allowed in my original (Mocha)  
Netscape 2-3 and rewritten (SpiderMonkey) Netscape 4-era  
implementations. JScript allowed them and the standard included them  
as a compromise (there were compromises in the "other direction").


> (Yes, I understand that they are disallowed in ES3.1 strict mode,  
> and that
> disallowing them in non-strict mode would break compatibility. I'm  
> just
> curious what was going through the minds of the ES1 standardizers.)

The rationale is lost to the mists of time. I vaguely recall some  
belief that looseness in other parts of the language justified  
allowing duplicate formals, but bad doesn't justify worse. The  
complexity involved in supporting duplicate formals (compiling and  
decompiling) is out of proportion to any subjective value in the  
"feature". Really, it's just a botch hammered out during ES1  
standardization based on JScript. There were botches on the JavaScript  
(Netscape) side too, so I'm not throwing stones.

Anyway, soon we can just "use strict" and move on. :-)

/be