Strengthening Function.prototype.toString

Karl Krukow karl.krukow at gmail.com
Fri Sep 26 00:38:18 PDT 2008


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.



More information about the Es-discuss mailing list