Bait taken: Arguments about arguments

Mark S. Miller erights at
Thu Jan 8 22:17:12 PST 2009

On Thu, Jan 8, 2009 at 9:30 PM, Brendan Eich <brendan at> wrote:

> The rationale "we dare not break" applies to other cases of making the
> strict mode migration tax too high. This came up in the wiki just now, and
> I've commented in-line at
> Spin-off thread fodder, change of subject appropriate if you take my bait
> ;-).

Regarding your inline

> (I thought I was clear enough at Kona, and Maciej was perfectly clear in
the ticket:


> (This is not what was agreed to at Kona. We need to talk about this at the
next face to face.

We have divergent memories of what was agreed. This is an issue I care about
a lot, so I'm confident I didn't simply forget. Probably we misunderstood
each other somehow. In any case, what matters now is that we come to

You write (with bullets turned into numbers):

    1) Mandating two arguments implementations is onerous.
    2) In no case must eager construction of an Array instance be required,
but web compatibility plus strict mode would seem to require it for
    3) The migration tax for strict mode should not be hiked to include
"find all the hidden aliasing dependencies in the legacy codebase you

Re #1: Allen and Crock relayed this concern. I am skeptical, as there's a
trivial source-to-source transformation from the language L1 that I would
prefer to program in to the language L2 that you would prefer to implement:

If strict function foo in language L1 mentions 'arguments' freely or
contains an occurrence of the eval operator (this is statically
determinable, and we do not count either 'arguments' or 'eval' in nested
functions), for example

    function foo(...) {
        "use strict";
        ... arguments ...

then translate it to strict function foo in language L2, where t1 represents
an variable name not otherwise mentioned in the program, as

    function foo(...) {
        "use strict";
        var t1 = Object.freeze(Array.slice(arguments, 0));
        ... t1 ...

In other words, in exactly these functions, snapshot arguments eagerly into
a genuine array, and then replace all further uses of arguments with the
variable holding that snapshot. It's not quite a source-to-source
translation, since additional magic is required for a free 'arguments'
within an eval()ed script to address t1 rather than L2's "arguments", which
doesn't exist in L1. Actual implementations can be more efficient than this,
but this transform is adequate to demonstrate lack of burden.

Re #2: If foo is a strict function, then foo.arguments throws an error. So
the only functions where we need this eager creation are those that either
need arguments anyway, or those that directly use the eval operator, both of
which are statically visible.

Re #3: Actual use of arguments aliasing is very rare. (Re bait, compare to
the frequency of feature testing.) We freeze arguments so most actual uses
of such aliasing will result in noisy failures. Probably much current
aliasing is more of a source of buggy behavior than a feature used
intentionally. It is good if strict mode exposes bugs in ported programs.
New programmers should learn the strict language first or only, so we want
to remove such landmines from it. Intentional use of aliasing is probably
about as common as intentional use of implicit wrapping, and so your #3
would equally argue against the happy bug fix agreement we just had.

Btw, I very clearly remember you agreeing in Kona that we should freeze
strict arguments for this reason. I raise this not to start a "But you said.
No you said" loop, but in hopes of jogging your memory. Do you remember

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Es-discuss mailing list