Strengthening Function.prototype.toString

Karl Krukow karl.krukow at gmail.com
Tue Sep 30 10:34:17 PDT 2008


On 30/09/2008, at 19.12, Eugene Lazutkin wrote:
> Karl Krukow wrote:
>>
>> 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?

Yes, exactly.

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


OK, for option 3 I don't know what to do, and I may have misunderstood  
you. But for 1 and 2, wouldn't it be possible to produce some source  
form from the byte code or ast?  I mean the source form doesn't have  
to be identical to any original source text, but may be generated on  
the fly.

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

Good. Your opinion and discussion is exactly what I was looking for.

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

Yes, it depends on existence of an AST. Different implementations  
could map their internal representation to a common standardized  
minimal representation which at least wouldn't require AST objects to  
be equal.

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


I respect you opinion.

/Karl



More information about the Es-discuss mailing list