Strengthening Function.prototype.toString

Eugene Lazutkin eugene.lazutkin at
Tue Sep 30 10:12:22 PDT 2008


Karl Krukow wrote:
>>> (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}])

My understanding you are not proposing this as a part of the standard, 
but rather how someone can implement the functionality, right?

> 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?

1) JIT can use an intermediate byte code that was most probably optimized.
2) JIT can use optimized syntax tree notation (I hope we'll go past that).
3) No JIT, the code is already (partially) compiled.

To sum it up: I don't see the practical need to keep the code in its 
source form around.

> I'm not convinced that it is 'complicated, resource-hungry or  
> redundant.'  At least I have an early prototype implementation, 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.

My intention was more humble: I wanted to voice my personal opinion on 
this matter rather than convincing anyone that my opinion is the 
ultimate truth. And I am sure that your solution works just fine barring 
small details of the performance testing.

Still I think requiring to keep the source code around other than for 
debugging is an overkill.

> 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.

Here we go again: you made another implicit assumption that AST are 
still around (and untransformed) when the code is running. And even one 
more: AST objects should be the same on all interpreters.

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

I think that there is one common flaw with both suggestions (the source 
code and the AST) --- they are too low-level, require too much 
JavaScript (parser + interpreter, even for AST), don't give much 
flexibility to implementers, and my prevent possible optimizations. I 
feel that more high-level (actually medium-level) constructs would give 
the flexibility for programmers and implementers without compromising 
the performance. Of course it is all predicated on the interest from 
users in this functionality, which is still to be seen.



More information about the Es-discuss mailing list