I pushed a patch to assign the init form to a keyword var only when the var is undefined, as described below.
(Also a couple of other minor things: to use a gensym rather than hard-coded E for error var in IGNORE-ERRORS and to generate correct code for ^ in variable names. A naming convention I've become enamored of lately is to have a variable X^ to mean "the preceding version of X" à la git.) On Tue, Jan 11, 2011 at 2:59 PM, Daniel Gackle <[email protected]>wrote: > 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 <[email protected]>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 <[email protected]>: >> > 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 >> > [email protected] >> > http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel >> > >> > >> >> _______________________________________________ >> parenscript-devel mailing list >> [email protected] >> http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel >> > >
_______________________________________________ parenscript-devel mailing list [email protected] http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
