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

[Daniel Gackle]

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 at 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 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/36aad803/attachment.html>