Strengthening Function.prototype.toString

Karl Krukow karl.krukow at gmail.com
Tue Sep 30 08:37:30 PDT 2008


On 27/09/2008, at 08.58, Eugene Lazutkin wrote:
>
> Karl Krukow wrote:
>>
>> However I would have to move from a form:
>>
>> (function(a,b) {return a+b;}).specialize({ a: 42})
>>
>> to
>>
>> (function(a,b) {return a+b;}).specialize([42])
>
> Does your example substitute a or b? How to indicate what parameter(s)
> you want to specialize?

In this second form, it would specialize the first parameter. To  
specialize the second, you would use

(function(a,b) {return a+b;}).specialize([undefined,42])

granted you would be unable to specialize using undefined as a value.

Alternatively you could use a form:

(function(a,b) {return a+b;}).specialize([{1: 42}])

>
> Another thing: your solution relies on keeping around potentially big
> function bodies in their textual form, and a full-blown parser (+
> interpreter, if you want to do optimizations while specializing)  
> written
> in JavaScript, while there is a parser already in the
> compiler/interpreter that is a part of a run-time (see eval()).

At least it depends on being able to produce a FunctionDeclaration  
which, when eval'ed, is equivalent to the original function. However,  
a JIT would have some representation of the function stored already,  
otherwise how would it emit code? Now I am theorizing, but wouldn't it  
just be adding another 'translation module' which emits code back in  
JavaScript?

Also, I am not convinced it is such a big issue, there are  
implementations that target also mobile devices which keep textual  
representations around. At least I know that V8 keeps the source  
around and emits code directly from that without an intermediate  
representation. But I am no expert so I will leave it to the  
implementers to judge :-)

> Sounds
> complicated, resource-hungry, and redundant. Why not implement
> specialize() at the interpreter/compiler level rather than hacking
> around with toString()? If we are to ask for features let's ask  
> big! ;-)
>

I'm not convinced that it is 'complicated, resource-hungry or  
redundant.'  At least I have an early prototype implementation, Jeene (http://code.google.com/p/jeene/ 
) which I feel is not too bad performance wise: it is a one pass  
solution as is based on Crockford's efficient Pratt parser.

However, you are right! I would actually like to 'ask big' ;-) If I  
could ask for more I would not ask for a specialize function directly  
in the environment. 'specialize' is just one application of a much  
more powerful concept which is the LISP code/data duality. Instead, I  
would ask for e.g., a Function.prototype.representation function that  
would return an object representing the abstract syntax tree of the  
function, perhaps even annotated with additional information (and  
perhaps a dual Function.prototype.compile). This would be even better  
as I wouldn't have to do the parsing myself.

Think I can have that? ;-) Thanks for your great reply.

/Karl




More information about the Es-discuss mailing list