parenscript-devel

parenscript-devel@common-lisp.net

373 discussions

[parenscript-devel] The next frontier?
by Daniel Gackle 01 Mar '10

01 Mar '10

Congratulations on the new release! This seems like a good time to ask: what (if any) are the next significant things that could and should be added to Parenscript? Put differently, what CL constructs are there that (a) haven't been tackled yet, and (b) have a reasonable mapping to JS? The latter is important to preserve the goals of efficient, readable, debuggable JS. Any suggestions? I nominate backquote/comma. At least at a 50,000 foot level, it seems like the sort of thing PS could do, and it's pretty obvious that it would be useful. Daniel

4 7

[parenscript-devel] New Parenscript version
by Vladimir Sedach 27 Feb '10

27 Feb '10

Exciting things in this release include the long-awaited implicit return functionality, multiple value return, a completely redone and updated manual in HTML format, and many bugfixes. The version naming scheme has now been changed to a <major>.<minor> format (the new release is version 2.1). Enjoy! Vladimir

1 0

[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] Discrepancy in MULTIPLE-VALUE-BIND
by Daniel Gackle 23 Feb '10

23 Feb '10

Looks like our implementation doesn't match CL's after all. (blah2-call) evaluates to (2 5) in Common Lisp, but [2, undefined] in Parenscript. (defun blah1 () (values 2 5)) (defun blah2 () (blah1)) (defun blah2-call () (multiple-value-bind (a b) (blah2) (list a b))) Daniel

2 2

[parenscript-devel] Symbol-macro clashes
by szergling 13 Feb '10

13 Feb '10

Hi list, Just a quick note. Something I discovered a while ago, which hasn't quite been affected by recent patches. There's a potential clash between symbol macros and normal symbols in parenscript. Sometimes, we don't want to macroexpand certain symbols: In Common Lisp, PS> (define-symbol-macro %cldata (list 1 2 3)) %CLDATA PS> (let ((%cldata (list 4 5 6))) %cldata) (4 5 6) In parenscript, PS> (define-ps-symbol-macro %data (list 1 2 3)) %DATA PS> (ps %data) "[1, 2, 3];" PS> (ps (let ((%data (list 2 4 5))) %data)) ; Evaluation aborted. The value (ARRAY 1 2 3) is not of type SYMBOL. [Condition of type TYPE-ERROR] The %data (binding) shouldn't be expanded, and the %data in the let body should now be "shadowed" by the new binding. This also occurs with LET*, FLET, and LABELS (what else have I missed?). I couldn't looked too closely, but recently, all the variable binding seem to have been refactored into the code for ps-special-form var, so perhaps this is now easier to fix. Cheers, Yong.

2 1

[parenscript-devel] Sharing code between client and server?
by Axel Rauschmayer 03 Feb '10

03 Feb '10

I would like to use Parenscript with ABCL and am hoping for a GWT-like experience. What is the best way to share code between client and server? - Do I use the Parenscript constructs on the server? Not having CLOS seems a shame. - How would one send objects between client and server? - As JSON? How would the conversion be performed? Thanks! Axel -- Axel Rauschmayer axel(a)rauschma.de http://www.pst.ifi.lmu.de/people/staff/rauschmayer/axel-rauschmayer/ http://2ality.blogspot.com/ http://hypergraphs.de/

2 2

[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

← Newer
1
...
18
19
20
21
22
23
24
...
38
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

parenscript-devel