- parenscript-devel - mailman3.common-lisp.net

[parenscript-devel] DEFMACRO/PS considered harmful
by Daniel Gackle 04 Jan '10

04 Jan '10

The following is probably overkill, since it may be that nobody is actually using the simple two-line macro that I'm about to propose getting rid of. But the issues here are at least marginally interesting and there may be some value in writing them up. There are two ways to define a macro to work in both Lisp and PS, DEFMACRO/PS and DEFMACRO+PS. The difference between the two is rather obscure. In practice, the main effect is that if you define your macro with the former, then PS will generate its code from the *Lisp* macroexpansion of the form. Out of dumb habit, my practice until recently was this: 1. Use DEFMACRO/PS, unless 2. A bug occurs because the Lisp macroexpansion makes no sense in JS; 3. Spend time tracking down the bug 4. Switch to DEFMACRO+PS in that case. Then it dawned on me that I had been bitten by this an embarrassing number of times. I decided to see what would happen if I replaced all uses of DEFMACRO/PS with DEFMACRO+PS in our code, and inspected a diff of the resulting JS. My two findings were: (1) I discovered several places where, unbeknowst to us, we were ending up with unintended JS. For example, if we DEFMACRO/PS'd a macro which expanded to a logical operator like AND, then PS would generate code from the Lisp macroexpansion of AND instead of the obvious &&. The resulting JS wasn't necessarily incorrect, but it was clearly the wrong code. (2) There were no cases at all where DEFMACRO+PS didn't do what we wanted. Accordingly, I propose that DEFMACRO/PS be eliminated: 1. It adds little if any value. 2. In the rare case that it does add value, you can easily define your macro explicitly to do what you want. 3. It's error-prone (including some errors that go without detection). 4. The distinction between it and DEFMACRO+PS confuses everybody who sees it for the first time (if not the first ten times). 5. It's a mistake to blur the distinction between the Lisp macro environment and the PS one. It's sometimes handy to make a macro to work the same way on both sides (DEFMACRO+PS), but that's not the same thing as mixing the underlying two environments. 6. As PS has evolved and we've learned more about how to use it well, DEFMACRO/PS is an anachronism. I think I might have been its original author, in which case I am certain that the thinking behind it was confused. In short, off with its head! Daniel

2 2

[parenscript-devel] Implicit return for function bodies
by Vladimir Sedach 28 Dec '09

28 Dec '09

Hello, Many of you have been asking for this for a long time, and based on feedback (as well as my own experience) the lack of this feature has been the biggest cause of bugs in PS code, so it's with a bit of joy that I just pushed out a patch to add implicit returns to PS functions (including lambdas and flet/labels) to the repository just now. Please try it out and report any bugs you find! Thank you, Vladimir

3 6

[parenscript-devel] Miscellaneous issues
by Daniel Gackle 28 Dec '09

28 Dec '09

Here are some things I ran across while inspecting the effect of implicit return on our code. 1. Recently, PS started putting curly braces around case blocks in switch statements. It seems like this is unnecessary, at least in the examples I was looking at. 2. I noticed that an space was inserted after "default:" in case statements. Since it's followed by a newline, this is unnecessary. I commited a patch to take the space out. This is of course a trivial issue, but it was messing up our diffs in certain circumstances. 3. When defining a setfable place as follows, (ps (defun (setf blah) (a b) (whatever))) and calling it as follows, (ps (setf (blah c) d))) PS insists on assigning the function arguments to temporarily variables before passing them to the function: "var _js16974 = c; var _js16973 = d; __setf_blah(_js16973, _js16974);" This makes me cringe. Is it really necessary? I'm thinking perhaps there's some weird case where you need to control evaluation differently, but it's obviously not doing so here. Daniel

2 2

[parenscript-devel] I just "ported" ParenScript to Narwhal, has a REPL now
by Nick Fitzgerald 26 Dec '09

26 Dec '09

My changes are here: http://github.com/fitzgen/parenscript They are a pretty big gross hack. Most of the changes are just adding the files necessary to make it a Narwhal[1] package but I also had to write a little command line script for parenscript. I'm sure it is horrible, I'm very inexperienced with lisp. I just thought you guys might want to know about the changes. The coolest thing is that Narwhal will give you a REPL for parenscript. Go ahead and incorporate the changes if you want, or not, just letting you know what I have done. Thanks for a wonderful project! _Nick_ [1] http://narwhaljs.org/

1 0

Re: [parenscript-devel] How to generate element[i].childNodes[0].nodeValue
by Wout Perquin 03 Dec '09

03 Dec '09

On Tue, 2009-11-24 at 19:42 +0000, Wout Perquin wrote: > Hi, > I would like to generate : > "var value = element[i].childNode[0].nodeValue" > in one sentence. > > Currently I have a workaround : > (ps:ps > (let ((foo (aref element i)) > (value (slot-value (aref foo.child-nodes 0)'node-value))))) > which renders : > "var foo = element[i]; > var value = foo.childNodes[0].nodeValue;" > > Is there another more direct way ? > Thanks in advance. > Wout Perquin

4 13

Re: [parenscript-devel] Implicit return for function bodies
by sblist＠me.com 02 Dec '09

02 Dec '09

Hi Vladimir, Another tricky area for implicit return is in IF/WHEN/UNLESS. What happens currently is that when a conditional is in an expression place (such as after a RETURN statement), it is converted into a ternary expression. This works when the branches of the conditional contain only assignments and expressions, but you get a syntax error if there is a switch, for, or while statement in the branch body. I'm not sure how to handle this in the general expression-place scenario, but it seems like implicit return should handle all of the conditional branches -- something like this: (ps (lambda () (when x y))) => "function () { return x ? y : null; };" becomes: (ps (lambda () (when x y))) => "if (x) { return y; };" or perhaps: (ps (lambda () (when x y))) => "if (x) { return y; } else { return null; };" - Scott On 2009-11-04, at 12:57 PM, Vladimir Sedach wrote: > Hello, > > Many of you have been asking for this for a long time, and based on > feedback (as well as my own experience) the lack of this feature has > been the biggest cause of bugs in PS code, so it's with a bit of joy > that I just pushed out a patch to add implicit returns to PS functions > (including lambdas and flet/labels) to the repository just now. Please > try it out and report any bugs you find! > > Thank you, > Vladimir > > _______________________________________________ > parenscript-devel mailing list > parenscript-devel(a)common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel

2 4

[parenscript-devel] Multiple value calls
by Red Daly 26 Nov '09

26 Nov '09

Hi Parenscripters, As far as I can tell, multiple-value function calls are a unique feature of lisp. I would like the ability to perform multiple-value calls in Parenscript but I don't know if a sane solution exists or not. Can anyone come up with a scheme for returning multiple values that translates well to Javascript? Ideally such a scheme would not introduce much overhead for usual functions that do not use or return multiple values (though perhaps setting some sort of global MV flag might be inexpensive enough). Functions that return multiple values should also only appear to return a single value when called by a function that expects only one return value (including native javascript functions). (defun paren-mv-returner () (return (values 1 2 3))) => function parenMvReturner() { /* do some magic with the values 2 and 3 */ return 1; } // one implementation might be var mv = undefined; function parenMvReturner() { mv = [2, 3]; return 1; } // this scheme needs to adjust the return statement of every function so it might not be sufficient // consider this other function function parenMySingleReturner () { var x = parenMvReturner();

3 10

[parenscript-devel] Of interest to those interested in Clojure
by Vladimir Sedach 12 Nov '09

12 Nov '09

Here's an interesting project that does something like Parenscript for CL, but for Clojure: http://github.com/arohner/scriptjure Vladimir

1 0

Re: [parenscript-devel] Implicit return for function bodies
by sblist＠me.com 05 Nov '09

05 Nov '09

Hi Vladimir, Thanks a lot for doing this work, it'll be seriously great to have implicit return! On 2009-11-04, at 12:57 PM, Vladimir Sedach wrote: > Hello, > > Many of you have been asking for this for a long time, and based on > feedback (as well as my own experience) the lack of this feature has > been the biggest cause of bugs in PS code, so it's with a bit of joy > that I just pushed out a patch to add implicit returns to PS functions > (including lambdas and flet/labels) to the repository just now. Please > try it out and report any bugs you find! The first one I encountered was to do with the special return handling for case/switch. 1) The return special form assumes the wrong switch/case structure for these statements, it should be: (switch-case what &rest clauses) rather than: (switch-case what clauses) ...in both the destructing code and the reconstruction of the clauses, having been updated with the return statement. 2) The return special form needs to handle break forms in switch/case; rather than wrapping a break statement, it should remove it and wrap the previous expression in the return statement. Here's the (incorrect) output that I'm getting after having fixed the first issue: (ps (lambda () (case 1 (0 1) (otherwise 2)))) "function () { switch (1) { case 0: 1; return break; default: return 2; }; };" I think we want to see: "function () { switch (1) { case 0: return 1; default: return 2; }; };" - Scott

2 3

[parenscript-devel] [PATCH] Make NIL the value (the last form in enclosing PROGN) of a LOOP macro with no default accumulator.
by sblist＠me.com 05 Nov '09

05 Nov '09

Hi Vladimir, You'll probably want to handle FOR, WHILE separately in the RETURN special form, but I think this works for our purposes with the existing support for PROGN. Generally, I think that the implicit return mechanism should try its utmost to avoid generating JS syntax errors. - Scott --- src/lib/ps-loop.lisp | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/lib/ps-loop.lisp b/src/lib/ps-loop.lisp index 7272247..8a383a4 100644 --- a/src/lib/ps-loop.lisp +++ b/src/lib/ps-loop.lisp @@ -325,4 +325,4 @@ ,@(initially loop) ,main ,@(finally loop)) - ,@(when (default-accum-var loop) `((return ,(default-accum- var loop))))))) + ,(aif (default-accum-var loop) it nil)))) -- 1.6.5.2

2 1