Bait taken: Arguments about arguments

Allen Wirfs-Brock Allen.Wirfs-Brock at microsoft.com
Fri Jan 9 13:11:28 PST 2009


I created distinct Trac tickets for the separable issues being discussed here:

Ticket #428 has been reopened and should be specifically about isArray and whether or not it return true for the arguments object
http://bugs.ecmascript.org/ticket/428

Ticket #447 is about whether or not arguments object/formal parameter sharing continues after a function return
http://bugs.ecmascript.org/ticket/447

Ticket #448 is about whether or  not the semantics of arguments objects should vary between normal and strict mode functions
http://bugs.ecmascript.org/ticket/448

From: es-discuss-bounces at mozilla.org [mailto:es-discuss-bounces at mozilla.org] On Behalf Of Mark S. Miller
Sent: Thursday, January 08, 2009 10:17 PM
To: Brendan Eich
Cc: es3.x-discuss at mozilla.org; es-discuss
Subject: Bait taken: Arguments about arguments

On Thu, Jan 8, 2009 at 9:30 PM, Brendan Eich <brendan at mozilla.com<mailto:brendan at mozilla.com>> 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

http://wiki.ecmascript.org/doku.php?id=meetings:minutes_dec_18_2008

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:

and

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

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 foo.arguments.
    3) The migration tax for strict mode should not be hiked to include "find all the hidden aliasing dependencies in the legacy codebase you inherited".


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 this?

--
   Cheers,
   --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20090109/ea211f68/attachment.html>


More information about the Es-discuss mailing list