forward-incompatible Function.prototype.toString requirement

Mark S. Miller erights at
Fri Apr 17 15:08:50 UTC 2015

On Fri, Apr 17, 2015 at 7:10 AM, Juriy Zaytsev <kangax at> wrote:

> I did some research on this just last year —
> (and originally back in 2009, when things were much wilder,
> Corresponding tests with notes —
> Cool, thanks. Lots of ancient history there. Of recent versions of
browsers / engines, what problems do you see in arriving at ES6 conformance?

Btw, I was amused to see the old Caja es5-to-es3 transpiler case in there:

function f(){}; // function f() { [cajoled code] }
var f = function(){}; // function f$_var() { [cajoled code] }

which does raise the issue of how transpilers should cope with these
requirements. If the source string produced does parse, what language layer
should it be expressed in?
(Note: Modern Caja uses SES, which usually does not transpile)

> Just few days ago, I've been also thinking to add tests to ES6 compat
> table checking these exact (ES6 introduced) "toString representation
> requirements" from

Please do! Beyond ES6 conformance, it looks like we could plausibly stdize
something like the following for the "must not parse" case:

    The function head should parse as some kind of function head.
    The function body must match /^\s*{\s*\[[^{}\[\]]*\]\s*}\s*$/
        { [ non-"{}[]"-text ] }

The proposal would effectively commit us to never introducing a future
syntax where this parses as a function body, addressing the issue Michael
raises at the beginning of this thread. It would also allow reliable
recognition of those cases intended not to parse for this reason, including
present code recognizing future code (modulo recognizing future function
heads :( ). Does this seem plausible?

Anyone care to write an initial concrete proposal?

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

More information about the es-discuss mailing list