parenscript-devel April 2012

parenscript-devel@common-lisp.net

4 participants
9 discussions

[parenscript-devel] Inconsistent compilation of the empty list?
by Daniel Gackle 27 Jul '12

27 Jul '12

I have some test data where occasionally an empty list appears as an element inside of some other list. It's getting compiled to the JS string "[]" when what I need is the array literal [], in a way that seems inconsistent. Specifically, these are good: PS> (ps []) "[];" PS> (ps '()) "[];" PS> (ps '(1 2)) "[1, 2];" But these are not, because they generate either the string '[]' or null as the second element, when what I need is the array literal []: PS> (ps '(1 [])) "[1, '[]'];" PS> (ps '(1 ())) "[1, null];" Is this an inconsistency? Is there a workaround? Daniel

2 1

[parenscript-devel] PS LOOP now supports key-value iteration and collection
by Daniel Gackle 08 May '12

08 May '12

I've made the following changes to PS LOOP and pushed them on a branch called "loop" pending the fixing of the pretty-printer as we discussed a couple weeks ago. These changes capture some idioms that were common in our code. They deviate from CL's LOOP (I could not bring myself to implement "BEING THE HASH-KEYS OF") in ways that are appropriate for JS semantics. Since PS LOOP was not fully compatible with CL's LOOP anyway, this is not much of a loss. (1) Added a FOR..OF clause that iterates through the keys of a JS object. This translates to JS's "for k in obj" loops and corresponds roughly to "loop for k being the hash-keys of" in CL. (ps (loop :for k :of obj :do (foo k))) "for (var k in obj) { foo(k); };" To bind both key and value, you specify a pair. (This is an icky bit of syntax but it feels like the least icky option of the ones I'm aware of.) (ps (loop :for (k v) :of obj :do (foo k v))) "for (var k in obj) { var v = obj[k]; foo(k, v); };" Destructuring works on the value position just like they do everywhere else, so you can unpack an array. (Note that in this example the key variable isn't needed so we can put NIL in there.) (ps (loop :for (nil (v1 v2)) :of obj :do (foo v1 v2))) "for (var _js23095 in obj) { var _js23096 = obj[_js23095]; var v1 = _js23096[0]; var v2 = _js23096[1]; foo(v1, v2); };" ... or named properties (by using keywords): (ps (loop :for (nil (:hello :world)) :of obj :do (foo hello world))) "for (var _js23097 in obj) { var var23099 = obj[_js23097]; var hello23101 = var23099.hello; var world23102 = var23099.world; foo(hello23101, world23102); };" Side note: To get the scoping right for parallel loop clauses is tricky because LOOP orders things "step test step test" where JS's FOR does "step step test test", meaning that the second step will be evaluated even if the first test fails. It got trickier with the introduction of FOR..OF, so I adopted a simpler implementation that has some advantages (much tighter generated loop code) but also some disadvantages: (a) it was a pain to support :INITIALLY clauses so I dropped them (I'd be surprised if anyone ever used it), and (b) complex loops sometimes require an extra temporary variable to track whether the loop is on its first iteration or not. (2) There is now a MAP..TO clause that works like COLLECT only instead of building an array, builds an object mapping keys to values: (ps (loop :for str :in strs :map str :to (length str))) "(function () { var _js23109 = strs.length; var map23110 = { }; for (var _js23108 = 0; _js23108 < _js23109; _js23108 += 1) { var str = strs[_js23108]; map23110[str] = str.length; }; return map23110; })();" (3) In FOR..ON, a BY term can now be an integer. For example, you can say "by 2" instead of "by #'cddr" which makes little sense for JS arrays: (ps (loop :for (key val) :on pairs :by 2 :do (foo key val))) "for (var _js23094 = pairs; _js23094.length > 0; _js23094 = _js23094.slice(2)) { var key = _js23094[0]; var val = _js23094[1]; foo(key, val); };" If BY doesn't get a number, it assumes it got a function: (ps (loop :for (key val) :on pairs :by blah :do (foo key val))) "for (var _js23112 = pairs; _js23112.length > 0; _js23112 = blah(_js23112)) { var key = _js23112[0]; var val = _js23112[1]; foo(key, val); };" Daniel

2 1

[parenscript-devel] Inaccurate lexical capture in loop
by Daniel Gackle 08 May '12

08 May '12

PS seems to think that the variable named BLOCK is being captured by the irrelevant lambda and inserts a WITH binding. PS> (ps (loop :for i :from 0 :below 5 :do (let ((block (elt blocks i))) (foo block) (lambda () nil)))) "for (var i = 0; i < 5; i += 1) { with ({ block : null }) { var block = blocks[i]; foo(block); function () { return null; }; }; };" This doesn't happen if you take out the lambda: PS> (ps (loop :for i :from 0 :below 5 :do (let ((block (elt blocks i))) (foo block)))) "for (var i = 0; i < 5; i += 1) { var block = blocks[i]; foo(block); };" ... or even if you rename BLOCK to B: PS> (ps (loop :for i :from 0 :below 5 :do (let ((b (elt blocks i))) (foo b) (lambda () nil)))) "for (var i = 0; i < 5; i += 1) { var b = blocks[i]; foo(b); function () { return null; }; };" I thought this might be because PS had compiled a different form where BLOCK was indeed captured by closure in a loop and was remembering this inappropriately. But that doesn't seem right because the problem is reproducible on a fresh restart of PS. Daniel

2 1

[parenscript-devel] Loop return values don't get returned
by Daniel Gackle 05 May '12

05 May '12

Commit 83f4ea appears to have implemented return values from loop expressions, which is great and something I've wanted for a long time. But there seems to be a bug insofar as the return values never actually get returned: An example is this FOR loop - foo() should return 40 but returns NaN (10 * null) instead: (defun foo () (* 10 (for ((i 0)) ((< i 10)) ((incf i)) (when (> i 3) (return i))))) => function foo() { return 10 * (function () { var loopResultVar6945 = null; for (var i = 0; i < 10; ++i) { if (i > 3) { loopResultVar6945 = i; break; }; }; loopResultVar6945; })(); }; I get the same result using the LOOP macro, and WHILE loops have the same problem. Daniel

2 1

[parenscript-devel] Printer inconsistencies as of 60154a
by Daniel Gackle 05 May '12

05 May '12

I've been trying to upgrade our PS version and have some problems to report. This email concerns issues with the changes to the printer in commit 60154a. Accordingly, the code samples below need to be formatted in a fixed-width font to be readable. Also, they're all in JS rather than PS for obvious reasons. I can provide the corresponding PS forms if desired. First, a simple for loop used to be printed like this: for (var n = 0; n < 10; n += 1) { blah(n); }; is now: for (var n = 0; n < 10; n += 1) { blah(n); }; Not sure if that was intended, but it's so nonstandard that I can't bear to look at it. If one were going to put line breaks in the for loop declaration, surely there ought to be a line per clause rather than an arbitrary break between the second and third. But three lines is too many and anyway the whole thing is weird; it really belongs on one line. Second, there seem to be bugs in how expressions in a comma-delimited list are line-separated and indented. Apologies for the contrived JS here, but I have to make the lines long enough to trigger an indentation. Code that used to be in one line like this: var obj = (obj3433 = { }, (obj3433.foooooooooooo = 'oooooooooooooooooooooooooooooooo', obj3433.baaaaaaaaar = 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa', obj3433)); is now being indented like this: var obj = (obj3433 = { }, (obj3433.foooooooooooo = 'oooooooooooooooooooooooooooooooo', obj3433.baaaaaaaaar = 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa', obj3433)); I like the idea, but it seems the third (and any subsequent) lines ought to be aligned with the second. Here's a real example of the same problem from our code: var bucket = (g4 = m1 - sol[label], (g5 = m2 - sol[label], (g6 = rcplus === 'col' ? rect3437[0] : rect3437[2], (g7 = rcplus === 'col' ? rect3437[1] : rect3437[3], rc === 'col' ? [g4, g5, g6, g7] : [g6, g7, g4, g5])))); There are other more complex examples of nested grouped expressions that are coming out pretty strangely: var sh = ( obj3439 = { markup : packIgrid(markup), tiling : csh.tiling, ultc : ultc, ultr : ultr }, ( (g3 = (it = csh.coldeltas, it != null && it !== false ? xcopy(it) : null), g3 != null ? (obj3439.coldeltas = g3) : null), ( g4 = (it3440 = csh.rowdeltas, it3440 != null && it3440 !== false ? xcopy(it3440) : null), g4 != null ? (obj3439.rowdeltas = g4) : null), obj3439)); It does seem like a good idea to not have all this on one line, but it's far from clear what the indentation policy is. Similar inconsistencies afflict curly braces: queueMsg(brl, { acknowledge : true }, mailbox); or: return ss.appointmentTicket = { col : c + (cols || 0), row : r + (rows || 0) }; and here's a monster one: var REGRESSIONS = [{ type : 'js', target : 'ff', file1 : 'f1', file2 : 'f2' }, { type : 'js', target : 'ie6', file1 : 'ie61', file2 : 'ie62' }, { type : 'js', target : 'ie7', file1 : 'ie71', file2 : 'ie72' }, { type : 'js', target : 'ie8', file1 : 'ie81', file2 : 'ie82' }, { type : 'js', target : 'safari', file1 : 'saf1', file2 : 'saf2' }, { type : 'js', target : 'chrome', file1 : 'chr1', file2 : 'chr2' }, { type : 'js', target : 'node', file1 : 'n1', file2 : 'n2' }, { type : 'html', target : 'ff', file1 : 'hf1', file2 : 'hf2' }, { type : 'html', target : 'ie6', file1 : 'hie61', file2 : 'hie62' }, { type : 'html', target : 'ie7', file1 : 'hie71', file2 : 'hie72' }, { type : 'html', target : 'ie8', file1 : 'hie81', file2 : 'hie82' }, { type : 'html', target : 'safari', file1 : 'hsaf1', file2 : 'hsaf2' }, { type : 'html', target : 'chrome', file1 : 'hchr1', file2 : 'hchr2' }, { type : 'css', target : 'chrome', file1 : 'c1', file2 : 'c2' }, { type : 'css', target : 'ie8', file1 : 'ie1', file2 : 'ie2' }]; I have some respect for how much harder this problem is than it appears to be, having worked on similar issues for our Numen REPL and not being too happy with what I came up with. That being said, these changes to the printer probably make the JS less readable in our case rather than more readable. It would be better to do less and have it be consistent. At a minimum, I hope we can fix the more indecorous areas. Daniel

2 3

[parenscript-devel] piece of code
by Haris Bogdanovich 30 Apr '12

30 Apr '12

Hi. Why doesn't this piece of code work ? (defpackage test-x (:use :cl :hunchentoot :cl-who :parenscript)) (in-package test-x) (setf *js-string-delimiter* #\") (defun index () (with-html-output-to-string (*standard-output* nil) (:html (:head (:script :type "texr/javascript" (str (ps (defun al () (alert)))))) (:body (:h2 "clijlkjlkjclk" :onclick (ps (al ()))))))) (push (create-prefix-dispatcher "/index" 'index) *dispatch-table*) (start (make-instance 'easy-acceptor)) Thanks

2 1

[parenscript-devel] Edward Tate's jquery-parenscript
by Vladimir Sedach 10 Apr '12

10 Apr '12

If you haven't seen it already: https://github.com/et4te/jquery-parenscript/blob/master/jquery-api.lisp Might be handy if you're using jQuery a lot. Vladimir

1 0

[parenscript-devel] install
by Haris Bogdanovich 10 Apr '12

10 Apr '12

Hi. Parescriipt comes in gz file format. With which program for Windows I decompress it ? Thanks

3 2

[parenscript-devel] Closures inside loops: when should values be captured?
by Daniel Gackle 07 Apr '12

07 Apr '12

When a closure is created inside a loop, PS wraps the closed-over variables using a JS WITH statement to ensure that each closure will get the values that existed at the time it was created. Here's an example from Vladimir's email to the list from Jan 30, 2011: (let ((foo (make-array 3))) (dotimes (i 3) (setf (aref foo i) (lambda () i))) (funcall (@ console log) (funcall (aref foo 0))) (funcall (@ console log) (funcall (aref foo 1))) (funcall (@ console log) (funcall (aref foo 2)))) This correctly prints 0,1,2 to the console. If PS didn't do this extra work and relied on JS scoping, the output would be 3,3,3 which is obviously (or at least arguably) incorrect. But this doesn't happen for variables declared prior to the loop form. Here is the above example written to use WHILE rather than DOTIMES: (let ((foo (make-array 3)) (i 0)) (while (< i 3) (setf (aref foo i) (lambda () i)) (incf i)) (funcall (@ console log) (funcall (aref foo 0))) (funcall (@ console log) (funcall (aref foo 1))) (funcall (@ console log) (funcall (aref foo 2)))) It prints 3,3,3. Of course, probably no one would use WHILE to write this particular loop, but it's easy to see how one might run in to the problem. In particular, the PS LOOP macro generates WHILE forms for many standard kinds of loop. That is how I ran across this issue: I have a LOOP form that builds a table of closures for asynchronous callback in a Node.js program and by the time these closures are called back, they no longer have their expected data - for exactly the same reason as the above example prints 3,3,3. My first question is: is this a bug? That is, if it's incorrect for the first loop to print 3,3,3, is it also incorrect for the second loop to do so? Daniel

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

parenscript-devel April 2012