[parenscript-devel] Evaluation of default values for keyword args
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
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
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@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@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
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 <danielgackle@gmail.com>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 <vsedach@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@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
participants (2)
-
Daniel Gackle -
Vladimir Sedach