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

[parenscript-devel] Why is there a WITH clause in my loop?
by Daniel Gackle 30 Jan '11

30 Jan '11

Here's a really strange one. We have a form like the following. I've stripped it down for brevity, so it looks weird: (loop :for time :from time1 :below time2 :do (when (foo (λ () (bar (λ () (blah)) time)) time) (break))) It used to generate this: for (var time = time1; time < time2; time += 1) { if (foo(function () { return barr(function () { return blah(); }, time); }, time)) { break; }; }; But now it generates this: for (var time = time1; time < time2; time += 1) { with ({ time : time }) { if (foo(function () { return bar(function () { return blah(); }, time); }, time)) { break; }; }; }; That is one weird WITH clause in there! No doubt it has something to do with lexical scoping magic going on under the hood. But I definitely don't want it in a performance-critical loop. Daniel

5 8

[parenscript-devel] Evaluation of default values for keyword args
by Daniel Gackle 11 Jan '11

11 Jan '11

I'm glad to see the tighter code being generated for keyword arguments, but I'm afraid there's a problem. If a default value is provided, it is now being evaluated whether it's needed or not: (defun blah (&key (param (long-running-computation))) (foo param)) => function blah() { var param = longRunningComputation(); var _js10 = arguments.length; // ... return foo(param); }; Compare this to: (defun blah (&optional (param (long-running-computation))) (foo param)) => function blah(param) { if (param === undefined) { param = longRunningComputation(); }; return foo(param); }; I think the above keyword behavior is incorrect and the optionals have it right. Yet I like the fact that all the sludge of the "if variable remains undefined after sucking out the optional arguments then set it to null" sort has been removed. Is there a compromise? For example, could we do it the simpler way where the default value is a constant? Daniel

2 3

[parenscript-devel] Over-aggressive expressification?
by Daniel Gackle 10 Dec '10

10 Dec '10

I noticed the JS for a function like this has changed: (defun blah () (when (some-condition) (foo) (bar) (baz))) It used to give this: function blah() { if (someCondition()) { foo(); bar(); return baz(); }; }; Now it produces this: function blah() { return someCondition() ? (foo(), barr(), baz()) : null; }; I think it's worth questioning whether this deviates too far from PS's goal of readable JS. I can give examples from our codebase where this approach produces very complex composite expressions that are quite unreadable. It doesn't bother me too much, since I understand what PS is doing and can always look at the source code. But it certainly sacrifices readability/debuggability. Too far? Daniel

2 1

[parenscript-devel] Syntax error: PS sometimes tries to treat throw like an expression
by Daniel Gackle 09 Dec '10

09 Dec '10

(defun blah () (let ((result (foo))) (unless (null result) (throw result)))) generates the syntactically incorrect: function blah() { var result = foo(); return result != null ? (throw result) : null; };

2 1

[parenscript-devel] Problem with BLOCK and RETURN-FROM
by Daniel Gackle 09 Dec '10

09 Dec '10

(1) The following expression generates the correct code: (defun blah () (λ () (foo 123))) But it also emits "Warning: Returning from unknown block NILBLOCK", which is undeserved. (2) It's not clear how to do explicit return from a lambda now. That is, (defun blah () (λ () (when (foo) (return 123)) ;; do some other stuff )) generates the same warning as above. Is this just a bug, or is it suggesting that one must explicitly declare a scope using (BLOCK NIL...) in order to do an explicit return warning-free? I'm hoping not the latter.

2 4

[parenscript-devel] Four PS bugs
by Daniel Gackle 06 Dec '10

06 Dec '10

Here are four problematic expressions. ;; crashes (defun foo () (let ((a (bar))))) ;; syntax err (defun foo () (let* ((a (bar))))) ;; returns nil (defun foo () "bar") ;; doesn't return nil (defun blah () (or (foo) (progn (bar) nil)))

2 4

[parenscript-devel] Patch: added JS label/break to PS
by Daniel Gackle 06 Dec '10

06 Dec '10

I just pushed a patch (authored by Scott) to implement JS's LABEL and BREAK in PS. (Note that this patch deprecates LABELED-FOR since you can get the same effect by combining LABEL and FOR. Was anybody using LABELED-FOR?) Here's an example: (label scope (foo) (when (bar) (break scope)) (blee)) => scope: { foo(); if (bar()) { break scope; }; blee(); }; I was astonished to discover recently that JS has supported this ability all along in the form of labeled statements and labeled breaks. I'd always assumed that to get explicit returns from an arbitrary scope, you'd have to resort to the ugly hack of muscling TRY/CATCH to do it, thinking that this was the closest JS counterpart. (See http://news.ycombinator.com/item?id=793092 for a thread in which several people believe this.) But it appears we were all wrong. What's not clear yet is how far this can be taken. Can you use it inside a nested local function to return immediately from the top-level function? That is one thing I've wanted for a long time. In the ideal case, LABEL/BREAK could be used as a base for implementing a proper BLOCK and RETURN-FROM in PS, something which we'd long believed to be impossible. One challenge is that in CL, RETURN-FROM can take a value, which becomes the value of BLOCK. In other words, BLOCK in CL is an expression while LABEL in JS is not. It seems, though, that most of this challenge has already been conquered with the development of implicit return in PS. The only thing you'd need to add is detecting when BLOCK is being used as an expression, declaring a gensymed variable and assigning whatever is happening inside BLOCK to that variable (much like implicit return already does with e.g. CASE), then put the variable in the expression position that BLOCK was in. It seems like this ought to work. It would also make things like this possible in PS: (1+ (case foo (:eleven 11) (:twelve 12))) Vladimir (and everybody), is the above clear? What do you think of it? Daniel

4 11

[parenscript-devel] [PATCH] Define bit-shifting special forms >> and <<, and ASH as a macro.
by sblist＠me.com 06 Dec '10

06 Dec '10

I'm not sure how you feel about adding >> and << as special forms, but this seems to allow for a simpler implementation of ASH since it needs to do some higher-level transformations such as optimizing forms with a a constant COUNT argument along with avoiding multiple evaluation. Scott --- src/macros.lisp | 14 ++++++++++++++ src/package.lisp | 4 ++++ src/printer.lisp | 2 +- src/special-forms.lisp | 4 +++- 4 files changed, 22 insertions(+), 2 deletions(-) diff --git a/src/macros.lisp b/src/macros.lisp index 2014330..2c0c295 100644 --- a/src/macros.lisp +++ b/src/macros.lisp @@ -59,6 +59,20 @@ (define-ps-symbol-macro pi (getprop *math '*pi*)) +(defpsmacro ash (integer count) + (let ((count (ps-macroexpand count))) + (cond ((and (numberp count) (> count 0)) `(<< ,integer ,count)) + ((numberp count) `(>> ,integer ,(- count))) + ((complex-js-expr? count) + (let ((count-var (ps-gensym))) + `(let ((,count-var ,count)) + (if (> ,count-var 0) + (<< ,integer ,count-var) + (>> ,integer (- ,count-var)))))) + (t `(if (> ,count 0) + (<< ,integer ,count) + (>> ,integer (- ,count))))))) + ;;; Types (defpsmacro stringp (x) diff --git a/src/package.lisp b/src/package.lisp index 7921a37..92922e7 100644 --- a/src/package.lisp +++ b/src/package.lisp @@ -99,6 +99,10 @@ #:logxor #:lognot + #:ash + #:>> + #:<< + #:* #:/ #:rem diff --git a/src/printer.lisp b/src/printer.lisp index 73df146..5f119b7 100644 --- a/src/printer.lisp +++ b/src/printer.lisp @@ -169,7 +169,7 @@ vice-versa.") (defprinter js:post-- (x) (ps-print x)"--") -(defprinter (js:+ js:- js:* js:/ js:% js:&& js:\|\| js:& js:\| js:-= js:+= js:*= js:/= js:%= js:^ js:&= js:^= js:\|= js:= js:== js:=== js:!== js:in js:!= js:> js:>= js:< js:<=) +(defprinter (js:+ js:- js:* js:/ js:% js:&& js:\|\| js:& js:\| js:-= js:+= js:*= js:/= js:%= js:^ js:&= js:^= js:\|= js:= js:== js:=== js:!== js:in js:!= js:> js:>= js:< js:<= js:<< js:>>) (&rest args) (loop for (arg . remaining) on args do (print-op-argument op arg) diff --git a/src/special-forms.lisp b/src/special-forms.lisp index 6633b2f..5ca7a52 100644 --- a/src/special-forms.lisp +++ b/src/special-forms.lisp @@ -25,7 +25,9 @@ logior js:\| logxor js:^ lognot js:~ - ;; todo: ash for shifts + + >> js:>> + << js:<< throw js:throw array js:array -- 1.7.2.1

2 2