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
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
