parenscript-devel December 2009

parenscript-devel@common-lisp.net

6 participants
9 discussions

[parenscript-devel] What about (declare (special foo))?
by Daniel Gackle 25 Jan '10

25 Jan '10

PS supports special variables but to use them requires declaring a variable with DEFVAR instead of VAR. I'm not fond of this because the DEFVAR-vs.-VAR distinction in PS doesn't fit with the DEFVAR-vs.-DEFPARAMETER distinction in CL (at least, I don't see the analogy if there is one). What I'd like is to be able to do this: (ps (let ((*foo* 123)) (declare (special *foo*)) (blah))) => "var FOO12733 = FOO; try { FOO = 123; blah(); } finally { FOO = FOO12733; };" Vladimir, do you think this would be hard to do? It's similar to how LET works on variables declared with DEFVAR. The difference of course is that here *FOO* stops being a special-variable when the DECLARE goes out of scope. Do you (or does anyone) think that the above would be a bad idea? If so, why? We have a macro right now that does the above in a somewhat ugly way, and it's very handy on the 3 or 4 occasions that we need it. Daniel

2 6

[parenscript-devel] Should implicit return in PS mean always explicitly returning null in JS?
by Daniel Gackle 25 Jan '10

25 Jan '10

I've now had a chance to systematically look at how our code fares under PS's implicit return. Thanks to Scott for being the guinea pig for the rest of us. I like it! I do have a few questions/issues. I'll send them in separate emails, I guess. PS now tries to insert a default "return null;" statement in functions that would formerly have returned nothing, i.e. whose return values would have been undefined. I am not convinced that this buys us much. We've always treated NULL and UNDEFINED as conveying the same information when returning from a function. I recognize not everyone would share this interpretation. The trouble with explicit "return null" is that you end up with things like the following example taken from our code (stripped-down for brevity): (defun blep (ss x y) (when foo? (awhen (bar) (destructuring-bind (c r) it (when (!null c r) (awhen (baz) (when (blah it) (unless (blee) t)))))))) => function blep(ss, x, y) { if (foowhat) { var it = bar(); if (it != null && it !== false) { var c = it[0]; var r = it[1]; if (c != null && r != null) { var it27537 = baz(); if (it27537 != null && it27537 !== false) { if (blah(it27537)) { if (!blee()) { return true; } else { return null; }; } else { return null; }; } else { return null; }; } else { return null; }; } else { return null; }; } else { return null; }; }; I wish PS would avoid generating all those "return null"s when the only thing we need is the "return true". Note also that PS is not *always* returning null; there are cases where the old undefined behavior still exists: (ps (defun foo () (dolist (a b) (blah a)))) => "function foo() { for (var a = null, _js_idx27540 = 0; _js_idx27540 < b.length; _js_idx27540 += 1) { a = b[_js_idx27540]; blah(a); }; };" Personally, I think this is fine and would rather see all functions behave this way. That is, if I put a NIL in a tail position in my code, I should get "return null" and otherwise no explicit return in JS. We can't factor the null vs. undefined distinction out of PS altogether; it's too engrained in JS. Anyway this issue is, to my mind, distinct from the implicit return feature as such. What am I missing? Daniel

4 8

[parenscript-devel] FLET name mangling
by sblist＠me.com 04 Jan '10

04 Jan '10

Is there any reason why FLET must mangle the function name when there is no name collision detected? I'd like to be able to do this: JS> (ps (flet ((foo () x)) (blah foo))) "var foo1 = function () { x; }; blah(foo);" ... without wrapping FOO in a FUNCTION form (this is JS-only code). - Scott

2 1

[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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

parenscript-devel December 2009