Strengthening Function.prototype.toString

Erik Arvidsson erik.arvidsson at gmail.com
Fri Sep 26 09:21:42 PDT 2008


If I remember correctly The reason for keeping it implementation  
dependent is so that devices with low memory would not have to keep a  
reversible implementation in memory. For example an implementation  
might have translated the whole function to machine code.

I know that Opera on mobile phones used to return a string  
representation that did not reflect the original.

-- 
Erik Arvidsson
Google

On Sep 26, 2008, at 0:38, Karl Krukow <karl.krukow at gmail.com> wrote:

> Hello everyone,
>
> I was exploring extending Crockford's Pratt parser to build a partial
> evaluator for JavaScript. One would extend Function.prototype with a
> specialize function, e.g.
>
> (function(a,b) {return a+b}).specialize({ a: 42 })
>
> would return a function equivalent to:
>
> function(b) {return 42+b}
>
> This technique relies on caling toString on functions. However, the
> ECMAScript 3.1 (and 3) specs says the following about
> Function.prototype.toString:
>
>
> 15.3.4.2 Function.prototype.toString ( )
> An implementation-dependent representation of the function is
> returned. This representation has the
> syntax of a FunctionDeclaration. Note in particular that the use and
> placement of white space, line
> terminators, and semicolons within the representation string is
> implementation-dependent...
>
>
> The phrase: "implementation-dependent" bothers me. It gives no
> guarantees that the function returned should bear any relation to the
> function on which toString is called. E.g., it would be legal to
> always return "function(){}".
>
> The sentence: "Note in particular that the use and placement of white
> space, line
> terminators, and semicolons within the representation string is
> implementation-dependent." seems to indicate the intention of
> "implementation-dependent" refers only to the "optional/non-semantic"
> parts of the definition. It is unclear, however.
>
> Effectively this means that programmers cannot rely on
> Function.prototype.toString in general, render it useless.
>
> My suggestion is to strengthen the contract to state something like:
> For any function f and any values x1, x2, ... , xn we have:
>
> eval(f.toString())(x1,x2,...,xn) === f(x1,x2,..., xn).
>
> Indicating also a semantic match.
>
> How do you feel about this suggestion? Here is my current list of Pros
> and Cons:
>
>
> Pros:
>
>  -- current large implementations already satisfy this. I've tested
> it on: Firefox 2, Firefox 3, Safari 3.2.1, IE6, IE7, the latest Opera,
> SquirrelFish Extreme, TraceMonkey and V8.
>
> -- It is powerful. When combined with a parser like Crockford's one  
> can use some powerful meta-programming techniques commonly only found
> in languages like Scheme and LISP.
>
> -- It should not be that hard to implement.
>
> Cons:
>
> -- There are some smaller implementations which do not satisfy this  
> semantic property.
>
> --  It would perhaps add more complexity to implementations and it  
> is  
> hard to test true equality of functions so you would have to prove it
> correct ;-)
>
>
> Hope to hear from you,
>
> -- Karl
>
> P.S. If you are interested in the partial evaluator project, Jeene, go
> to: http://blog.higher-order.net.
>
> _______________________________________________
> Es-discuss mailing list
> Es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss


More information about the Es-discuss mailing list