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

[parenscript-devel] Problems with new object initalization
by Victor 02 Apr '13

02 Apr '13

Hello, I would like to express following line of code: var myLogReader = new YAHOO.widget.LogReader('myLogger'); in Parenscript-Lisp. According to the reference manual it might be something like: (defvar my-log-reader (new (@ *yahoo* widget LogReader "myLogger"))) but I get a completely different result. What is the proper way to express such kind of statements in Parenscript? By the way, contrary to the reference manual, `var' form is not turned into a variable declaration in JavaScript. Thanks, Victor

3 4

[parenscript-devel] Repost: Re: 'use strict' and 'with' in loop
by Peter Wood 24 Mar '13

24 Mar '13

The reply bounced due to excessive message size, and I couldn't cancel, so I'm resending anyway ... Hi Daniel Thanks for your reply. Strict mode makes life a bit easier because I have a lot of scripts which get loaded and unloaded and I want to be careful about namespaces. In strict mode, eval is not allowed to introduce new variables into the surrounding namespace. 'Arguments' are also simpler and cleaner. More importantly, I _think_ it makes javascript slightly less insecure: see https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Functions_and… Maybe it's like bolting your front door even though all your windows are still open, but presumably better than nothing. It is also claimed that using strict mode enables the engine to make a number of optimizations, which certainly won't hurt if it's true. (To sum up, I think it's a better language in strict mode.) I have read through your discussion with Vladimir from last year, and I can see that my offhand suggestion was terribly naive. <cringe>. Multiple value return in js is obviously an "interesting" problem. Certainly, none of the ideas I have considered myself can solve all the problems. Doing a _completely_ CL-alike multiple value return scheme would seem bound to make the compiler a great deal more complex for quite small returns (no pun intended). I'm not too keen on the global variable,but that's my problem. Of course, it would have to be declared if it should work in strict mode. At the risk of embarrassing myself again: what about having a values macro return a closure which holds the multiple-value array and which pops a value off it every time it gets called? If you only want to return 1 value from values, or null, the macro could deal with that, and if you want to return a single function, ie (values (lambda () ...), the macro could wrap it in a lambda, to allow the pop() to return the desired anonymous function. The multiple-value-bind receiving macro could bind the functions appropriately. Something like vlet* could nest calls to multiple-value-bind if you want to mix local assignment of strings and numbers and calls to multiple-value-returning functions but only use the first value. It will still break if you bind a var to the return value of a non-values-lambda-returning-function, since vlet* assumes that function values must be popped (ie, funcalled). Just in case this idea is worth something, I am attaching these three macros ('fvals, 'fmvb and 'vlet*) which seem to do at least some of what is wanted, with some test cases. And yes, it would be great to have compilation to Lua! Lua is very nice. Regards, Peter

1 0

[parenscript-devel] 'use strict' and 'with' in loop
by Peter Wood 23 Mar '13

23 Mar '13

Hi It's my first post, so first of all, thanks to everyone who works on parenscript. It is a lifesaver. If I 'use strict'; in the start of my scripts, they fail in some of the loops because parenscript is generating a 'with' (which is not allowed in strict mode). There is quite a nice explanation of why it isn't allowed here: https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Functions_and… It is easy to change my code to use 'do' instead, and for now, that's what I've done, but it's a shame not to be able to use parenscript's very nice loop for writing javascript loops. I haven't looked at parenscript's code before this evening, but I think this is the relevant spot (in src/special-operators.lisp) (defun compile-loop-body ... (aif (sort (remove-duplicates *loop-scope-lexicals-captured*) #'string< :key #'symbol-name) `(ps-js:block (ps-js:with ,(compile-expression `(create ,@(loop for x in it collect x collect (when (member x loop-vars) x)))) ,compiled-body)) compiled-body))) Here is an example of some lisp and the js which it generates: (ps:ps (defun foo () (loop for i from 1 to 5 append (loop for j from 1 to 5 collect (list i j))))) ==> "function foo() { return (function () { var append9 = []; for (var i = 1; i <= 5; i += 1) { with ({ i : i }) { ^^^^^^^^^^ append9 = append9.concat((function () { var collect10 = []; for (var j = 1; j <= 5; j += 1) { collect10['push']([i, j]); }; return collect10; })()); }; }; return append9; })(); };" What is the point of even having the 'with ({ i : i })' in there ?? I have tried removing the form starting (ps-js:with ... ) and the code which is then generated runs fine and has no 'with', but of course it is probably breaking something else. I don't understand why it's there. Regards, Peter

2 5

[parenscript-devel] An experimental implementation of source mappings
by Daniel Gackle 14 Mar '13

14 Mar '13

I have committed an experimental branch called "srcmap" that contains an implementation of source mappings for Parenscript. By "source mappings" I mean a way of associating the text extent (start and end position in PS source code) of PS forms with the corresponding positions in generated JS code. There's a more detailed description in the commit message (053e9d4). Note that this Lispy form-based approach is not the same as the line-based approach of the Google/Mozilla source map spec. I believe it ought to be fairly easy to transform this format into that one, but have not done that work yet. Since this implementation had to modify the compiler every place that forms are transformed along the path from PS input to JS output, it has a fairly large footprint in the codebase (though not as large as you might expect: less than 200 lines of code were added, and only about 100 in the core compiler). Doing this work I ran into a bunch of places in the code where minor refactoring would help, as well as a handful of bugs. I kept all of that carefully separate from the source map commit itself, and have pushed it in the form of about a half-dozen commits onto master. That way the work of maintaining the srcmap branch until the day (if ever) that it is merged into master will at least be limited to relevant parts of the code. One of those commits was to move BIND out of deprecation hell and into lib/ps-loop.lisp. Since LOOP isn't deprecated and it relies on BIND, this seems the best place for BIND to live for now; especially since LOOP itself deviates from CL about as much as BIND does. Daniel

1 0

[parenscript-devel] defpsmacro has no effect at compile-time
by Peter Stirling 07 Mar '13

07 Mar '13

Hi, When you use C-c C-k in emacs/SLIME/sbcl produces the output: "(function () { var div1 = createElement(div); return null; })();" If you do C-C C-k again though, you get the (expected) output: "(function () { var div = document.createElement('DIV'); return null; })();" The problem is (I think) that DEFPSMACRO expands into a PROGN and therefore the SETFs have no effect until load time, by which point the PS form has already been converted into the string. If changed to an EVAL-WHEN: (defmacro defpsmacro (name args &body body) (defined-operator-override-check name (multiple-value-bind (macro-fn-form effective-lambda-list) (make-ps-macro-function args body) `(eval-when (:compile-toplevel :load-toplevel :execute) (setf (gethash ',name *macro-toplevel*) ,macro-fn-form) (setf (gethash ',name *macro-toplevel-lambda-list*) ',effective-lambda-list) ',name)))) Then it compiles as expected the first time as well.

1 1

[parenscript-devel] Bug fix: WITH-SLOTS and multiple evaluation
by Daniel Gackle 01 Mar '13

01 Mar '13

WITH-SLOTS had a problem with multiple evaluation: (ps (with-slots (a b) (foo) (+ a b))) => "foo().a + foo().b;" I pushed a fix for that. Patch below. Daniel commit 305778c609dd6102b4a313ef436985551c29ee18 Author: Daniel Gackle <danielgackle(a)gmail.com> Date: Fri Mar 1 17:17:04 2013 -0700 Fixed bug: multiple evaluation in WITH-SLOTS. diff --git a/src/macros.lisp b/src/macros.lisp index 5537872..b75f4b0 100644 --- a/src/macros.lisp +++ b/src/macros.lisp @@ -140,10 +140,11 @@ (if (listp slot) (second slot) slot))) - `(symbol-macrolet ,(mapcar (lambda (slot) - `(,(slot-var slot) (getprop ,object ',(slot-symbol slot)))) - slots) - ,@body))) + (maybe-once-only (object) + `(symbol-macrolet ,(mapcar (lambda (slot) + `(,(slot-var slot) (getprop ,object ',(slot-symbol slot)))) + slots) + ,@body)))) ;;; multiple values diff --git a/t/output-tests.lisp b/t/output-tests.lisp index 361cd8b..f2d856c 100644 --- a/t/output-tests.lisp +++ b/t/output-tests.lisp @@ -141,6 +141,13 @@ (+ a b c)) "this.a + this.b + this.c;") +(test-ps-js with-slots-single-eval + (lambda () (with-slots (a b) (foo) (+ a b))) + "(function () { + var object1 = foo(); + return object1.a + object1.b; +});") + (test-ps-js object-literal-quoted-symbols (create 'test "bang" 'symbol-saved-my-life "parenscript") "({ 'test' : 'bang', 'symbolSavedMyLife' : 'parenscript' });")

1 0

[parenscript-devel] Refactoring: getting rid of the specialized equality op printer
by Daniel Gackle 24 Feb '13

24 Feb '13

I pushed a refactoring patch (4a55356 - reproduced below) that needs some review. The idea is that the equality operators don't need to be printed differently from the other operators. They were, in order to allow for a function #'parenthsize-equality to ensure that expressions like (= (= a b) c) and (= a (= b c)) are printed with parenthesized operands. However, as I read the code, there is no possibility that the default operator printer would ever not parenthesize those operands. In other words, the mechanism is superfluous. A further explanation is given in the commit message below. All the tests pass and I observe no change in the compiled output of our application, but this is still the kind of change that someone should look over. Daniel commit 4a55356d6d09715fbd10a01c1b9019e013e42663 Author: Daniel Gackle <danielgackle(a)gmail.com> Date: Sun Feb 24 17:09:41 2013 -0700 Refactoring: got rid of PARENTHESIZE-EQUALITY. There is no need for PARENTHESIZE-EQUALITY as distinct from PRINT-OP-ARGUMENT, because the latter always parenthesizes equality expressions when they are an operand in some other equality expression. (In such a case, OP and ARG-OP have the same precedence, and neither is associative.) diff --git a/src/printer.lisp b/src/printer.lisp index 348f55a..f07a5b2 100644 --- a/src/printer.lisp +++ b/src/printer.lisp @@ -145,10 +145,8 @@ vice-versa.") (defmethod ps-print ((number number)) (format *psw-stream* (if (integerp number) "~D" "~F") number)) -(defvar %equality-ops '(ps-js:== ps-js:!= ps-js:=== ps-js:!==)) - (let ((precedence-table (make-hash-table :test 'eq))) - (loop for level in `((ps-js:getprop ps-js:aref ps-js:funcall) + (loop for level in '((ps-js:getprop ps-js:aref ps-js:funcall) (ps-js:new) (ps-js:lambda) ;; you won't find this in JS books (ps-js:++ ps-js:-- ps-js:post++ ps-js:post--) @@ -157,7 +155,7 @@ vice-versa.") (ps-js:- ps-js:+) (ps-js:<< ps-js:>> ps-js:>>>) (ps-js:< ps-js:> ps-js:<= ps-js:>= ps-js:instanceof ps-js:in) - ,%equality-ops + (ps-js:== ps-js:!= ps-js:=== ps-js:!==) (ps-js:&) (ps-js:^) (ps-js:\|) @@ -218,21 +216,12 @@ vice-versa.") (defprinter ps-js:post-- (x) (ps-print x)"--") -(defprinter (ps-js:+ ps-js:- ps-js:* ps-js:/ ps-js:% ps-js:&& ps-js:\|\| ps-js:& ps-js:\| ps-js:-= ps-js:+= ps-js:*= ps-js:/= ps-js:%= ps-js:^ ps-js:<< ps-js:>> ps-js:&= ps-js:^= ps-js:\|= ps-js:= ps-js:in ps-js:> ps-js:>= ps-js:< ps-js:<=) +(defprinter (ps-js:+ ps-js:- ps-js:* ps-js:/ ps-js:% ps-js:&& ps-js:\|\| ps-js:& ps-js:\| ps-js:-= ps-js:+= ps-js:*= ps-js:/= ps-js:%= ps-js:^ ps-js:<< ps-js:>> ps-js:&= ps-js:^= ps-js:\|= ps-js:= ps-js:in ps-js:> ps-js:>= ps-js:< ps-js:<= ps-js:== ps-js:!= ps-js:=== ps-js:!==) (&rest args) (loop for (arg . remaining) on args do (print-op-argument op arg) (when remaining (format *psw-stream* " ~(~A~) " op)))) -(defprinter (ps-js:== ps-js:!= ps-js:=== ps-js:!==) (x y) - (flet ((parenthesize-equality (form) - (if (and (consp form) (member (car form) %equality-ops)) - (parenthesize-print form) - (print-op-argument op form)))) - (parenthesize-equality x) - (format *psw-stream* " ~A " op) - (parenthesize-equality y))) - (defprinter ps-js:aref (array &rest indices) (print-op-argument 'ps-js:aref array) (dolist (idx indices)

1 0

[parenscript-devel] Side effects between lexical scopes of two closures
by Daniel Gackle 19 Feb '13

19 Feb '13

In the following, (FOO) should evaluate to 50, but actually evaluates to 90 because BAR's A binding has overwritten FOO's. Should they not have separate bindings? (progn (let ((a 5)) (defun foo () (* 10 a))) (let ((a 9)) (defun bar () (* 100 a)))) var a = 5; function foo() { return 10 * a; }; var a = 9; function bar() { return 100 * a; }; Daniel

2 1

[parenscript-devel] Bug: PS deprecation warnings not printing in CCL
by Daniel Gackle 31 Jan '13

31 Jan '13

Deprecation warnings don't print for me in CCL. I see this: Compiler warning: In a toplevel form: Nonspecific warning While executing: PARENSCRIPT::WARN-DEPRECATED, in process worker(13). If, however, I change 'simple-style-warning to 'simple-warning in WARN-DEPRECATED, I see this: Warning: LABEL is deprecated, use BLOCK instead While executing: PARENSCRIPT::WARN-DEPRECATED, in process worker(13). Much better. It would be helpful, though, if there were a way to track down the offending form. Grepping my code doesn't reveal any use of LABEL, for example, so I'm not sure what's triggering the warning. Is there or could there be a way to do this? Daniel p.s. A clue to the bug: if I change 'simple-style-warning to 'style-warning and call warn-deprecated from the REPL, I get this: :format-control is an invalid initarg to initialize-instance for #<standard-class style-warning>. Valid initargs: (:function-name :source-note :warning-type :args). [Condition of type ccl::simple-program-error]

1 0

[parenscript-devel] maybe-once-only
by Daniel Gackle 30 Jan '13

30 Jan '13

I heartily approve of the introduction of MAYBE-ONCE-ONLY in a5cf0df, because it drives me nuts (perhaps irrationally) to see superfluous bindings in generated code. If nothing else, they detract from PS's goal of producing readable JS. Upgrading our codebase to use the latest Parenscript from git, I noticed this macro and saw an opportunity to remove a bit of code we wrote that does the same thing. Doing so, I noticed the following four things. 1. MAYBE-ONCE-ONLY wasn't being exported, so I modified package.lisp to do that. Should "ps" be in the name, in that case? MAYBE-ONCE-ONLY is a good name (it certainly kicks the name we were using's butt, as you will see below), but already a little on the verbose side, and MAYBE-PS-ONCE-ONLY is over my comfort limit in that respect. So I left the name as is. 2. There is a problem with symbol macros leading to multiple evaluation: (defpsmacro true? (x) (maybe-once-only (x) `(and (!null ,x) (not (= ,x false))))) (define-ps-symbol-macro aaa (bar)) (defun foo () (symbol-macrolet ((bbb (bar))) (when (true? bbb) (baz))) (when (true? aa) (baz))) => function foo() { if (bar() != null && bar() !== false) { baz(); }; return bar() != null && bar() !== false ? baz() : null; }; Note that this is true for both kinds of symbol macro — top-level and local — as the example shows. 3. The generated code evaluates bound expressions in reverse order of appearance in the code. I don't know if this would ever be a problem, but the principle of least surprise probably cautions against it. That is, in the following form, (bar) should probably be evaluated before (baz): (defmacro+ps blah (a b) (maybe-once-only (a b) `(list ,a ,b))) (defun foo () (blah (bar) (baz))) => function foo() { var b3600 = baz(); var a3599 = bar(); return [a3599, b3600]; }; 4. Finally, here for comparison purposes is the macro I removed from our code in order to use MAYBE-ONCE-ONLY instead. It has a worse name, the horrible ONCE-WHEN (I couldn't come up with anything better), but I think I prefer its implementation for a couple of reasons: it doesn't suffer from the two problems (symbol macros and evaluation order) mentioned above, and it delegates to the classic ONCE-ONLY (PS-ONCE-ONLY in our case) for all of the macro magic, which makes it shorter and easier to follow. (defun atomic? (expr) (or (atom expr) (atom (ps::ps-macroexpand expr)))) (defmacro once-when (vars &body body) (cond ((= (length vars) 1) `(cond ((atomic? ,(car vars)) ,@body) (t (ps-once-only (,(car vars)) ,@body)))) (t `(once-when (,(car vars)) (once-when ,(cdr vars) ,@body))))) Perhaps the two implementations can be combined into something better. Daniel

1 0