I've published an initial proposal here: https://github.com/michaelficarra/Function-prototype-toString-revision
Feel free to add comments by opening a Github issue or pull request. I will add this proposal to the agenda for this week's meeting. On Fri, Apr 17, 2015 at 9:08 AM, Mark S. Miller <[email protected]> wrote: > On Fri, Apr 17, 2015 at 7:10 AM, Juriy Zaytsev <[email protected]> wrote: > >> I did some research on this just last year — >> http://perfectionkills.com/state-of-function-decompilation-in-javascript/ >> (and originally back in 2009, when things were much wilder, >> http://perfectionkills.com/those-tricky-functions/) >> >> Corresponding tests with notes — >> http://kangax.github.io/jstests/function-decompilation/ >> >> 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 19.2.3.5. >> > > 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*$/ > i.e., > { [ 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? > > -- > Cheers, > --MarkM > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > > -- Shape Security is hiring outstanding individuals. Check us out at *https://shapesecurity.com/jobs/ <https://shapesecurity.com/jobs/>*
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
