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