[parenscript-devel] The implementation of keyword parameters

Red Daly reddaly at stanford.edu
Thu Aug 9 21:08:39 UTC 2007


In lisp, function calls supply a list that is destructured by the 
receiving function.  Compilers optimize calls to known functions by 
doing the argument decomposition at compile-time.  When a function call 
is being made to function the compiler cannot deduce, the argument list 
is destructured at runtime.

Optimistically we can apply the same principles to Parenscript 
arguments.  A single function definition with keyword arguments could be 
split into more functions, one which does all the argument processing at 
run-time and another which accepts pre-processed arguments.  The 
compiler could decide which to call when optimizing.

Of course, this requires semantic analysis and an optimization phase, 
neither of which the compiler has of yet.  Furthermore, it is unclear 
how inefficient the current protocol is.  If you think the keyword 
argument processing is too slow, then you might want to do without it 
for very heavily used functions.  In most cases, however, it should be 
fast enough.

One thing you should note is that functions act on the keyword object 
destructively.  We might want to change this behavior so that the key 
objects can be reused.

Thanks,
Red

[1] 
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=javascript&lang2=sbcl

Daniel Gackle wrote:
> I like the addition of keyword params but using a json object to store 
> the key params at runtime adds some overhead that I'm wondering if we 
> could avoid. Could we make the compiler generate regular JS functions 
> with ordered signatures? For example:
>
>   (ps (defun f(&key a b)))
>
> would turn into:
>
>   function f(a b) { }
>
> and the compiler would take care of detecting function calls and 
> generating params in the right order. So:
>
>   (ps (f :a 1 :b 2)) => f(1,2)
>
> while
>
>   (ps (f :b 1 :a 2)) => f(2, 1)
>  
> What do you guys think?
>  
> Daniel
>  
> p.s. This may sound like excessive optimization, but on our project 
> efficiency is critical and we do a ton of profiling. We have some 
> functions that are good candidates for &key signatures, but not if 
> they get slower.
> ------------------------------------------------------------------------
>
> _______________________________________________
> parenscript-devel mailing list
> parenscript-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
>   




More information about the parenscript-devel mailing list