That is indeed a bug. Here's the solution I came up with:

(defun blah (&key (param (long-running-computation)))
 (foo param))

=>

function blah() {

   var _js4 = arguments.length;
   for (var n3 = 0; n3 < _js4; n3 += 2) {
       switch (arguments[n3]) {
       case 'param':
           param = arguments[n3 + 1];
       };
   };
   var param = param ? param : longRunningComputation();
   return foo(param);
};

Believe it or not, this actually does the right thing when param has
previously been declared as a global variable.

Vladimir

2010/12/7 Daniel Gackle <danielgackle@gmail.com>:

> I'm glad to see the tighter code being generated for keyword
> arguments, but I'm afraid there's a problem. If a default value is
> provided, it is now being evaluated whether it's needed or not:
> (defun blah (&key (param (long-running-computation)))
>   (foo param))
> =>
> function blah() {
>     var param = longRunningComputation();
>     var _js10 = arguments.length;
>     // ...
>     return foo(param);
> };
> Compare this to:
> (defun blah (&optional (param (long-running-computation)))
>   (foo param))
> =>
> function blah(param) {
>     if (param === undefined) {
>         param = longRunningComputation();
>     };
>     return foo(param);
> };
> I think the above keyword behavior is incorrect and the optionals have
> it right. Yet I like the fact that all the sludge of the "if
> variable remains undefined after sucking out the optional arguments
> then set it to null" sort has been removed.
> Is there a compromise? For example, could we do it the simpler way
> where the default value is a constant?
> Daniel

> _______________________________________________
> parenscript-devel mailing list
> parenscript-devel@common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
>
>

_______________________________________________
parenscript-devel mailing list
parenscript-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel