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