[parenscript-devel] Evaluation of default values for keyword args

Daniel Gackle danielgackle at gmail.com
Tue Jan 11 21:59:10 UTC 2011


I'm still encountering a bug with this issue: The JS incorrectly assigns the
default value when the caller supplies a value for PARAM that is NIL (or 0,
or false).

I suppose the immediate fix is to only assign the default value when PARAM
is undefined?

I'm a little uncomfortable relying on the serious weirdness of JS
surrounding global/local vars in order to implement this feature, but if
there's no other alternative that is both correct and equally fast as this
one, then I guess that trumps other concerns.



On Thu, Dec 9, 2010 at 11:41 PM, Vladimir Sedach <vsedach at gmail.com> wrote:

> 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 at 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 at common-lisp.net
> > http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
> >
> >
>
> _______________________________________________
> parenscript-devel mailing list
> parenscript-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/parenscript-devel/attachments/20110111/ec07f883/attachment.html>


More information about the parenscript-devel mailing list