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.
+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@gmail.comwrote:
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@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
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@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@gmail.comwrote:
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@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
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@gmail.comwrote:
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@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@gmail.comwrote:
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@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
parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
< why not just use an object as the only parameter >
That was the first way we did it, and we changed it for a good reason, but my recollection of why is fuzzy. Does anybody remember? The archives of this list may be helpful here.
I believe the reason may have been that it places an undue burden on the caller. If I want to write something like this...
(member item arr :key foo :test bar)
... who is going to figure out that the last 4 arguments are really two keyword params and bundle them into { key : foo, test : bar }?
You could make the caller do it:
(member item arr (create :key foo :test bar))
... but then you lose interoperability with CL, and arguably dilute the feature to the point where you might as well not have it, since it's easy enough to define a function that takes a js object as its last parameter and picks out the keys.
On the other hand, you could make PS do it by decreeing that keywords in an arglist *always* identify keyword params, but that breaks this:
(member :blah arr :key foo :test bar)
... which now generates member({blah : arr, key : foo, test : bar}) instead of the desired member("blah", arr, {key : foo, test : bar}). In other words, this option makes the semantics of keywords inconsistent in PS.
Another option is to make the PS compiler consider the signature of the function being called before it generates the code for the call. That complicates the compiler and IIRC is hard to get working in the general case (Vladimir can comment here).
So my recollection is that we settled on the existing method as the one that places no burden on either the caller or the callee (at the source level... obviously the JS that's generated for the callee is what does all the extra work), preserves the semantics of keywords, is closest to how CL does keyword args, and keeps the compiler simple.
On Thu, Aug 5, 2010 at 2:47 PM, Nick Fitzgerald fitzgen@gmail.com wrote:
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@gmail.comwrote:
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@gmail.comwrote:
+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@gmail.comwrote:
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@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
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
Yes, pretty much. When Red Daly made his original patch (http://common-lisp.net/pipermail/parenscript-devel/2007-July/000294.html) there was an "options" parameter. The problem is there's no guarantee the function arglist will be known before there's a call to that function in the code, so the first keyword encountered in the function call argument list triggered the creation of the "options" object, which meant you couldn't pass keywords as function arguments.
JS's arguments array is one of my favorite parts of the language.
Vladimir
2010/8/5 Daniel Gackle danielgackle@gmail.com:
< why not just use an object as the only parameter > That was the first way we did it, and we changed it for a good reason, but my recollection of why is fuzzy. Does anybody remember? The archives of this list may be helpful here. I believe the reason may have been that it places an undue burden on the caller. If I want to write something like this... (member item arr :key foo :test bar) ... who is going to figure out that the last 4 arguments are really two keyword params and bundle them into { key : foo, test : bar }? You could make the caller do it: (member item arr (create :key foo :test bar)) ... but then you lose interoperability with CL, and arguably dilute the feature to the point where you might as well not have it, since it's easy enough to define a function that takes a js object as its last parameter and picks out the keys. On the other hand, you could make PS do it by decreeing that keywords in an arglist *always* identify keyword params, but that breaks this: (member :blah arr :key foo :test bar) ... which now generates member({blah : arr, key : foo, test : bar}) instead of the desired member("blah", arr, {key : foo, test : bar}). In other words, this option makes the semantics of keywords inconsistent in PS. Another option is to make the PS compiler consider the signature of the function being called before it generates the code for the call. That complicates the compiler and IIRC is hard to get working in the general case (Vladimir can comment here). So my recollection is that we settled on the existing method as the one that places no burden on either the caller or the callee (at the source level... obviously the JS that's generated for the callee is what does all the extra work), preserves the semantics of keywords, is closest to how CL does keyword args, and keeps the compiler simple.
On Thu, Aug 5, 2010 at 2:47 PM, Nick Fitzgerald fitzgen@gmail.com wrote:
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@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@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@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@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
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
parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
Ah! Very good points, thank you for the explanation.
_Nick_
On Thu, Aug 5, 2010 at 2:13 PM, Daniel Gackle danielgackle@gmail.comwrote:
< why not just use an object as the only parameter >
That was the first way we did it, and we changed it for a good reason, but my recollection of why is fuzzy. Does anybody remember? The archives of this list may be helpful here.
I believe the reason may have been that it places an undue burden on the caller. If I want to write something like this...
(member item arr :key foo :test bar)
... who is going to figure out that the last 4 arguments are really two keyword params and bundle them into { key : foo, test : bar }?
You could make the caller do it:
(member item arr (create :key foo :test bar))
... but then you lose interoperability with CL, and arguably dilute the feature to the point where you might as well not have it, since it's easy enough to define a function that takes a js object as its last parameter and picks out the keys.
On the other hand, you could make PS do it by decreeing that keywords in an arglist *always* identify keyword params, but that breaks this:
(member :blah arr :key foo :test bar)
... which now generates member({blah : arr, key : foo, test : bar}) instead of the desired member("blah", arr, {key : foo, test : bar}). In other words, this option makes the semantics of keywords inconsistent in PS.
Another option is to make the PS compiler consider the signature of the function being called before it generates the code for the call. That complicates the compiler and IIRC is hard to get working in the general case (Vladimir can comment here).
So my recollection is that we settled on the existing method as the one that places no burden on either the caller or the callee (at the source level... obviously the JS that's generated for the callee is what does all the extra work), preserves the semantics of keywords, is closest to how CL does keyword args, and keeps the compiler simple.
On Thu, Aug 5, 2010 at 2:47 PM, Nick Fitzgerald fitzgen@gmail.com wrote:
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@gmail.comwrote:
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@gmail.comwrote:
+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@gmail.comwrote:
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@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
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
parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
I pushed a patch that simplifies keyword and optional parameter processing.
I don't know what browsers you're targeting, but if you want even less noise, set *js-target-version* to 1.6 and it will use Array.indexOf to get at the keywords.
Vladimir
2010/8/4 Daniel Gackle danielgackle@gmail.com:
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@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
It looks like this change broke the &KEY-OBJECT parameter (at least for my branch). It also seems to incorrectly identify non-keyword arguments that happen to match keyword args
(defun xxx (&key foo) foo)
(xxx :bar :foo :foo 7) ;; => 'foo', but should be 7
I don't mind the loop approach, though it would be nice to lessen the generated code.
Red
On Tue, Aug 17, 2010 at 10:33 PM, Vladimir Sedach vsedach@gmail.com wrote:
I pushed a patch that simplifies keyword and optional parameter processing.
I don't know what browsers you're targeting, but if you want even less noise, set *js-target-version* to 1.6 and it will use Array.indexOf to get at the keywords.
Vladimir
2010/8/4 Daniel Gackle danielgackle@gmail.com:
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@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
It looks like this change broke the &KEY-OBJECT parameter (at least for my branch).
I forgot that even existed. Did it break for JS target version >= 1.6, or the regular method?
It also seems to incorrectly identify non-keyword arguments that happen to match keyword args
(defun xxx (&key foo) foo)
(xxx :bar :foo :foo 7) ;; => 'foo', but should be 7
Thank you for noticing that. Fixing the code is not trivial (unless there's an easy way of saying "find indexOf only at odd indices"), so there would really not be much difference between the two versions of the generated code in terms of size. I've decided to just remove the indexOf approach entirely.
Vladimir
I don't mind the loop approach, though it would be nice to lessen the generated code.
Red
On Tue, Aug 17, 2010 at 10:33 PM, Vladimir Sedach vsedach@gmail.com wrote:
I pushed a patch that simplifies keyword and optional parameter processing.
I don't know what browsers you're targeting, but if you want even less noise, set *js-target-version* to 1.6 and it will use Array.indexOf to get at the keywords.
Vladimir
2010/8/4 Daniel Gackle danielgackle@gmail.com:
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@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
parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
parenscript-devel@common-lisp.net
-
Daniel Gackle -
Nick Fitzgerald -
Red Daly -
Vladimir Sedach