forward-incompatible Function.prototype.toString requirement

Mark S. Miller erights at google.com
Thu Apr 16 14:33:40 UTC 2015


I agree with all this. Let's gather current precedent across JS
implementations of function printings are not and should not be parseable
and see if we can extract a clear spec that is consistent enough with
current reality.


On v8:
> Object
function Object() { [native code] }
> Object.bind(Object)
function () { [native code] }

On SpiderMonkey:
> Object
function Object() {
    [native code]
}
> Object.bind(Object)
function Object() {
    [native code]
}

On JSC:
> Object
function Object() {
    [native code]
}
> Object.bind(Object)
function Object() {
    [native code]
}


Looks promising so far! Anyone care to do a more complete investigation and
write up an initial proposal?




On Thu, Apr 16, 2015 at 7:13 AM, Frankie Bagnardi <f.bagnardi at gmail.com>
wrote:

> I just meant that it seems confusing that it can both produce a FunctionExpression
> and "return a string for which eval will throw a SyntaxError exception."
>
> I didn't mean to highjack this thread; the concern in the original email
> is noteworthy.  There should be recommended syntaxes which future versions
> of the spec agree not to break, including current browser implementations.
> This gives any future engines, or modifications to current engines a
> clearly defined acceptable way to format these strings.
>
> This also gives libraries which parse functions at runtime (despite how
> good of an idea this is) quick bail cases without using eval.  Examples of
> this are angular and require.js.
>
>
>
> On Thu, Apr 16, 2015 at 6:55 AM, Mark S. Miller <erights at google.com>
> wrote:
>
>>
>>
>> On Thu, Apr 16, 2015 at 6:36 AM, Andreas Rossberg <rossberg at google.com>
>> wrote:
>>
>>> On 16 April 2015 at 14:34, Frankie Bagnardi <f.bagnardi at gmail.com>
>>> wrote:
>>>
>>>> The part that sticks out to me is... toString on functions currently
>>>> throws a syntax error when eval'd for non-named functions.  Tested in
>>>> chrome:
>>>>
>>>> var f = function(){ return 1 };eval(f.toString()); // SyntaxError
>>>> // becausefunction(){ return 1 }; // SyntaxError
>>>> // but, force an expression: eval("(" + f.toString() + ")") // essentially clones f
>>>>
>>>>>>>> This... is confusing in my opinion.
>>>>
>>>
>>> Yeah, the spec says:
>>>
>>> "The string representation must have the syntax of a FunctionDeclaration
>>> FunctionExpression, GeneratorDeclaration, GeneratorExpression,
>>> ClassDeclaration, ClassExpression, ArrowFunction, MethodDefinition, or
>>> GeneratorMethod depending upon the actual characteristics of the object."
>>>
>>> which is weird. First, it doesn't really make sense, because whether
>>> something originates from a declaration vs expression isn't a
>>> "characteristic of the object". Second, making it return different
>>> syntactic classes in different cases is not particularly useful for your
>>> case.
>>>
>>> But then again, using the result of f.toString as input to eval is A
>>> REAL BAD IDEA anyway; toString should only be used for diagnostics, not
>>> programmatically, because that is meaningless in general. So I personally
>>> don't mind the friction.
>>>
>>
>> Disagree. The purpose of this change in toString spec from ES5 is
>> primarily to support pass-by-copy closed functions. The intent was that it
>> always work to evaluate them as expressions, i.e., with the surrounding
>> parens.
>>
>> http://wiki.ecmascript.org/doku.php?id=harmony:function_to_string
>> http://wiki.ecmascript.org/doku.php?id=strawman:concurrency#there
>>
>>
>>
>>
>>>
>>> /Andreas
>>>
>>>
>>>
>>>>
>>>>
>>>> On Thu, Apr 16, 2015 at 2:56 AM, Andreas Rossberg <rossberg at google.com>
>>>> wrote:
>>>>
>>>>> On 16 April 2015 at 11:34, Michael Ficarra <mficarra at shapesecurity.com
>>>>> > wrote:
>>>>>
>>>>>> ES2015 section 19.2.3.5 (Function.prototype.toString) places four
>>>>>> restrictions on the output of Function.prototype.toString, one of which is
>>>>>>
>>>>>> If the implementation cannot produce a source code string that meets
>>>>>>> these criteria then it must return a string for which *eval* will
>>>>>>> throw a *SyntaxError* exception.
>>>>>>>
>>>>>>
>>>>>> What is a SyntaxError today may not be a SyntaxError tomorrow. How
>>>>>> can an implementation return a string that will satisfy this requirement in
>>>>>> the future when the language has added new syntax? Does the committee have
>>>>>> a SyntaxError recommendation that can be added as a non-normative note to
>>>>>> that section?
>>>>>>
>>>>>
>>>>> In the (probably unlikely) case that the language changed that way,
>>>>> and an affected implementation adopted that change, then it would simply
>>>>> have to change its toString implementation accordingly at that point. I
>>>>> don't see a problem there.
>>>>>
>>>>> /Andreas
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> es-discuss mailing list
>>>>> es-discuss at mozilla.org
>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>>
>> --
>>     Cheers,
>>     --MarkM
>>
>
>


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


More information about the es-discuss mailing list