parenscript-devel January 2013

parenscript-devel@common-lisp.net

6 participants
15 discussions

[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 31 Jan '13

31 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

[parenscript-devel] No-op LETs shouldn't thwart the expressionizer
by Daniel Gackle 31 Jan '13

31 Jan '13

These two forms seem like they ought to generate the same code, but don't: (defun foo () (when (bar) (baz))) function foo() { return bar() ? baz() : null; }; (defun foo () (when (bar) (let () (baz)))) function foo() { if (bar()) { return baz(); }; }; Although one wouldn't write an empty LET by hand, macros that accumulate bindings sometimes emit them. If those macros are widely used in a program, one can lose quite a few desirable 'expressionizations' this way. I've committed a patch (see below) to tweak the function TRY-EXPRESSIONIZING-IF? into exempting empty LETs from the nesting heuristic it uses to decide what to expressionize. Vladimir, please revise or revert it I did it wrong. This came up because I'm trying to port my code to use the MAYBE-ONCE-ONLY macro introduced in a5cf0df, rather than a similar one I wrote. I'll post about that momentarily. Daniel diff --git a/src/special-operators.lisp b/src/special-operators.lisp index 0267133..799d70f 100644 --- a/src/special-operators.lisp +++ b/src/special-operators.lisp @@ -222,7 +222,8 @@ (try-expressionizing-if? (or (ignore-errors (ps-macroexpand x)) x) ;; fail (+ score (case (car exp) - ((if cond let) 1) + ((if cond) 1) + (let (if (second exp) 1 0)) ;; ignore empty binding list ((progn) (1- (length (cdr exp)))) (otherwise 0)))))) (t t)))

1 0

[parenscript-devel] CoffeeScript Soaks
by David Sargeant 29 Jan '13

29 Jan '13

It would be great to be able to do "soaks" like in CoffeeScript. Example from coffeescript.org: zip = lottery.drawWinner?().address?.zipcode Produces var zip, _ref; zip = typeof lottery.drawWinner === "function" ? (_ref = lottery.drawWinner().address) != null ? _ref.zipcode : void 0 : void 0;

2 1

[parenscript-devel] DEFINE-PS-SYMBOL-MACRO
by David Sargeant 19 Jan '13

19 Jan '13

What does (DEFINE-PS-SYMBOL-MACRO symbol expansion) do? I found the following in non-cl.lisp, which got me thinking. (define-ps-symbol-macro {} (create)) Is there some way to extend the reader so that you could do {:name "David" :age 34} instead of (create :name "David" :age 34)? David

2 1

[parenscript-devel] ++ and --
by David Sargeant 19 Jan '13

19 Jan '13

(++ x) => plus(x); and (-- x) => (x); Is this correct behavior? David

2 1

[parenscript-devel] Renaming a Macro
by David Sargeant 18 Jan '13

18 Jan '13

What is the best way to rename a macro in ParenScript? For example, if I wanted to use '->' instead of 'chain.' Right now I am just using a macro, but I'm wondering if there is an easier way. Thanks. (defmacro -> (&rest method-calls) `(chain ,@method-calls)) David

2 1

[parenscript-devel] A more useful destructuring bind
by David Sargeant 18 Jan '13

18 Jan '13

The current DESTRUCTURING-BIND could be much more useful if you could pull apart objects and arrays. CoffeeScript has a great mechanism for this (http://coffeescript.org/#destructuring). Below is an example of what this macro might look like in parenscript. Let me know your thoughts. David (d-bind (:obj name (:obj firstname lastname) likes (:arr first-like second-like)) (create :name (create :firstname "Joe" :lastname "Blo") :occupation "Web Developer" :likes '("programming" "woodworking" "cycling")) (alert (+ "Your name is " firstname " and you like " first-like)))

3 5

Re: [parenscript-devel] A more useful destructuring bind
by David Sargeant 17 Jan '13

17 Jan '13

The functionality in bind is really great. Are just you suggesting moving it out of parenscript proper? David

2 1

Re: [parenscript-devel] Loops that return a value
by David Sargeant 17 Jan '13

17 Jan '13

That code doesn't work properly in parenscript, btw. It does not decrement. (function () { var collect66 = []; for (var num = 10; num <= 1; num += 1) { collect66['push'](num); }; return collect66; })();

3 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

parenscript-devel January 2013