[parenscript-devel] Tighter keyword arguments?

Nick Fitzgerald fitzgen at gmail.com
Thu Aug 5 20:47:24 UTC 2010


Ok, I just realized that I completely misread your original post. I thought
you were proposing the removal of defaulting to null rather than leaving the
value undefined.

Have you done any profiling to see if there is a reasonable difference
between

"function foo() {
    var a;
   // ... pick out and assign keyword args ...
    if (a === undefined) {
        a = null;
    };
    return bar(a);
};"

and

"function foo() {
    var a = null;
   // ... pick out and assign keyword args ...
    return bar(a);
};"

?

I just ran this very naive test in Chromium:

var then = +new Date;
var i = 20000;
while (i--) {
  (function () {
     var a;
     if (a === undefined) a = null;
  }())
};
console.log(+new Date - then);

Which logs 70 ms.

var then = +new Date;
var i = 20000;
while (i--) {
  (function () {
     var a = null;
  }())
};
console.log(+new Date - then);


This one logs 71 ms.

This has to have come up before, but why not just use an object as the only
parameter and use it's keys as the keyword arguments? I just ran the same
test for that, and when the keyword was missing I got 82 ms, but when it was
available, I got 56.

I think using objects would make the generated code much more readable,
which trumps speed in this case IMO given that the difference is so small
and the high number of iterations being performed.

_Nick_



On Thu, Aug 5, 2010 at 1:24 PM, Daniel Gackle <danielgackle at gmail.com>wrote:

> Good point. I kept the null assignment for consistency with how PS does
> &optional
> arguments. But this begs the question: why do we care about &optional
> and &key arguments being set to null, as opposed to just leaving them
> undefined?
> I'm trying to remember the reason... anybody?
>
> Our experience has been that PS code works best if one treats null and
> undefined
> as interchangeable. But that may be an artifact of running some of the same
> code
> in CL as well, where there is no such distinction.
>
>
> On Thu, Aug 5, 2010 at 1:51 PM, Nick Fitzgerald <fitzgen at gmail.com> wrote:
>
>> +1 from me but that doesn't mean too much.
>>
>> No need to explicitly set them as `null`, because JS already has (the more
>> semantic in this case) `undefined`.
>>
>> _Nick_
>>
>>
>>
>> On Wed, Aug 4, 2010 at 12:30 PM, Daniel Gackle <danielgackle at gmail.com>wrote:
>>
>>> The code that's generated for a keyword argument goes like this:
>>>
>>> (ps (defun foo (&key a) (bar a)))  =>
>>>
>>> (abbreviated for clarity):
>>>
>>> "function foo() {
>>>     var a;
>>>    // ... pick out and assign keyword args ...
>>>     if (a === undefined) {
>>>         a = null;
>>>     };
>>>     return bar(a);
>>> };"
>>>
>>> It seems to me that this could be made tighter as follows:
>>>
>>> "function foo() {
>>>     var a = null;
>>>    // ... pick out and assign keyword args ...
>>>     return bar(a);
>>> };"
>>>
>>> The only difference I can think of is when someone explicitly passes
>>> undefined
>>> as a value for the argument, but that's an oxymoronic thing to do.
>>>
>>> Can anyone think of a reason not to make this change? I like PS's keyword
>>> arguments a lot, but the generated JS is bloated enough to make me wince.
>>>
>>> _______________________________________________
>>> 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
>>
>>
>
> _______________________________________________
> 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/20100805/c2818dec/attachment.html>


More information about the parenscript-devel mailing list