parenscript-devel January 2010

parenscript-devel@common-lisp.net

3 participants
6 discussions

[parenscript-devel] Skipping null returns at the top level.
by szergling 27 Feb '10

27 Feb '10

Hi folks, I was wondering if there's an idiom for skipping the generation of a form completely at the top-level. This is mildly related to the implicit return feature currently being trialled. Here's an example: suppose I'm trying to skip over this form: (in-package :something-something) by using (defpsmacro in-package (x) nil) An in-package form then compiles to "null;" This spurious output may result in errors (I'm using ps to convert my Lisp code to Actionscript). How about using (values) to indicate explicitly that something doesn't have any return values? Yong.

2 8

[parenscript-devel] Release candidate
by Vladimir Sedach 25 Jan '10

25 Jan '10

I'm planning a new release of Parenscript. Everyone is encouraged to check out the repository version and report any bugs or issues you find. This time I'm also planning to switch the Parenscript version naming convention to numbered (instead of dated) releases. I want to call this upcoming release "2.1" Vladimir

1 0

[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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

parenscript-devel January 2010