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

[parenscript-devel] emacs uprading trick
by William Halliburton 16 May '09

16 May '09

To help convert older parenscript scripts into the latest fashions. ;; ps-upgrade.el ;; converts foo.baz.boz -> (@ foo baz boz) (defun ps-upgrade () (interactive) (let ((sym (symbol-at-point))) (delete-region (beginning-of-thing 'symbol) (end-of-thing 'symbol)) (insert "(@ " (substitute ?\s ?. (symbol-name sym)) ")"))) ;(global-set-key "\C-c\C-v" 'ps-upgrade)

1 0

[parenscript-devel] Bug: symbol macros have stopped working some of the time
by Daniel Gackle 15 May '09

15 May '09

Given this: (ps (define-symbol-macro foo 123)) These work: (ps foo) => "123; (ps (return foo)) => "return 123;" But these do not: (ps (list foo)) => "[foo];" (ps (create foo 456)) => "{ foo : 456 };" (ps (return (if (blah) foo blech))) => "return blah() ? foo : blech;"

2 1

[parenscript-devel] New patch that adds real lexical scoping and maybe breaks your code
by Vladimir Sedach 15 May '09

15 May '09

Hi, I just pushed a patch into the repository that may break existing code. Here is the patch description: Implemented LET and LET* by variable renaming, which provides the correct scoping semantics, and simplifies both the producing and the produced code. Removed the "." and "[]" name-mangling conventions from symbol-to-js-string. Any code that uses symbols such as "foo.bar[baz]" will now issue a warning, and needs to be rewritten to use standard Lisp accessors. This is needed for variable renaming to work, and is an extension of the patch that eliminated the ".method" method-calling convention. Thanks to Daniel Gackle and Dough Hoyte for opening my eyes to this technique, which was right in front of me all along. This is a win-win situation for everyone involved (yes, even if it breaks your code, think of it as an opportunity for refactoring). With this patch Parenscript is finally rid of the evil symbol-abuse conventions, which IMO is the only thing from the original design of Parenscript that can in retrospect be called a mistake. Let me know what you guys think. Thank you, Vladimir

4 7

[parenscript-devel] Bug: macroexpansion broken by lexical scoping change
by Daniel Gackle 10 May '09

10 May '09

Here's one thing that the latest PS breaks in our code. (ps (list 1 2 3)) => "[1,2,3];" (ps (let ((list nil)) (setf list (list 1 2 3)))) => "var list5180 = null; list5180 = list5180(1, 2, 3);" I think this behavior is incorrect. It is quite surprising for a lexical variable to shadow a macro definition. Daniel

2 4

[parenscript-devel] Bug: Latest PS breaks how quoted symbols were handled before
by Daniel Gackle 09 May '09

09 May '09

The latest PS interprets QUOTE of a symbol to mean, "first convert this symbol to a Javascript identifier, then a string". This breaks our code, because our formula parser relies on symbols to represent operators. Here's a line of code that PS was generating for us nicely before: (defparameter *op-symbols* '(| | + - * / ^ < > = <> <= >= & % ! { } [ ] |(| |)| |:| |,| |"| |'|)) => var OPSYMBOLS = [' ', '+', '-', '*', '/', '^', '<', '>', '=', '<>', '<=', '>=', '&', '%', '!', '{', '}', '[', ']', '(', ')', ':', ',', '"', '\'']; In the new PS, it looks like this: var OPSYMBOLS = [' ', 'plus', '', 'star', 'slash', '^', '<', '>', 'equals', '<>', '<equals', '>equals', '&', 'percent', 'bang', '{', '}', '[', ']', '(', ')', 'colon', ',', '"', '\'']; I think this is a mistake. The only reason for translating symbols like + to "plus" is if you want to use them in a JS identifier. But quoted symbols are not meant to turn into JS identifiers, only JS strings. Looking at the git log, this change was introduced into special-forms.lisp by commit dd4442b8973fe8b2c19b44f94f244934aa418ae8. This was submitted at the time as a bug fix. From our point of view, this "fix" introduces a bug, and quite a serious one, since it means we can't run our formula parser (and a few other things) in the browser. Daniel

3 4

[parenscript-devel] Added support for supplied-p parameters to optional and keyword arguments
by Daniel Gackle 09 May '09

09 May '09

I extended PS's optional and keyword arguments to handle supplied-p parameters. Patch below. Daniel >From b2c6b36e0c3582be703f861170fd6d2ea9cba4c6 Mon Sep 17 00:00:00 2001 From: Daniel Gackle <danielgackle(a)gmail.com> Date: Fri, 8 May 2009 15:13:18 -0600 Subject: [PATCH 2/2] Added support for supplied-p parameters to optional and keyword arguments. --- src/special-forms.lisp | 24 ++++++++++++++---------- 1 files changed, 14 insertions(+), 10 deletions(-) diff --git a/src/special-forms.lisp b/src/special-forms.lisp index a6d363f..7ac8e77 100644 --- a/src/special-forms.lisp +++ b/src/special-forms.lisp @@ -252,9 +252,11 @@ Syntax of key spec: (values (if (symbolp spec) spec (first spec)) (when (listp spec) (second spec)))) -(defpsmacro defaultf (place value) - `(when (=== ,place undefined) - (setf ,place ,value))) +(defpsmacro defaultf (name value suppl) + `(progn + ,@(when suppl `((var ,suppl t))) + (when (=== ,name undefined) + (setf ,name ,value ,@(when suppl (list suppl nil)))))) (defun parse-extended-function (lambda-list body &optional name) "Returns two values: the effective arguments and body for a function with @@ -264,11 +266,12 @@ the given lambda-list and body." ;; list of variable names, and you have access to the arguments variable inside the function: ;; * standard variables are the mapped directly into the js-lambda list ;; * optional variables' variable names are mapped directly into the lambda list, - ;; and for each optional variable with name v and default value d, a form is produced - ;; (defaultf v d) + ;; and for each optional variable with name v, default value d, and + ;; supplied-p parameter s, a form is produced (defaultf v d s) ;; * keyword variables are not included in the js-lambda list, but instead are ;; obtained from the magic js ARGUMENTS pseudo-array. Code assigning values to - ;; keyword vars is prepended to the body of the function. + ;; keyword vars is prepended to the body of the function. Defaults and supplied-p + ;; are handled using the same mechanism as with optional vars. (declare (ignore name)) (multiple-value-bind (requireds optionals rest? rest keys? keys allow? aux? aux more? more-context more-count key-object) @@ -282,8 +285,9 @@ the given lambda-list and body." (mapcar #'parse-optional-spec optionals)))) (opt-forms (mapcar #'(lambda (opt-spec) - (multiple-value-bind (var val) (parse-optional-spec opt-spec) - `(defaultf ,var ,val))) + (multiple-value-bind (var val suppl) + (parse-optional-spec opt-spec) + `(defaultf ,var ,val ,suppl))) optionals)) (key-forms (when keys? @@ -291,11 +295,11 @@ the given lambda-list and body." (with-ps-gensyms (n) (let ((decls nil) (assigns nil) (defaults nil)) (mapc (lambda (k) - (multiple-value-bind (var init-form keyword-str) + (multiple-value-bind (var init-form keyword-str suppl) (parse-key-spec k) (push `(var ,var) decls) (push `(,keyword-str (setf ,var (aref arguments (1+ ,n)))) assigns) - (push (list 'defaultf var init-form) defaults))) + (push (list 'defaultf var init-form suppl) defaults))) (reverse keys)) `(,@decls (loop :for ,n :from ,(length requireds) -- 1.6.1

2 1

[parenscript-devel] Extended DESTRUCTURING-BIND to allow NIL bindings
by Daniel Gackle 09 May '09

09 May '09

I extended DESTRUCTURING-BIND to allow NIL bindings to indicate a place should be ignored, the way that CL LOOP does. The fact that CL's DESTRUCTURING-BIND doesn't do that, but instead forces the user to make up a name and declare it ignored, is a perennial annoyance. Patch is below. Daniel >From 5d8b60256a70788c0930724e9d3501551a5e1559 Mon Sep 17 00:00:00 2001 From: Daniel Gackle <danielgackle(a)gmail.com> Date: Fri, 8 May 2009 14:59:05 -0600 Subject: [PATCH 1/2] Extended DESTRUCTURING-BIND to allow NIL bindings to indicate a place should be ignored, the way that CL LOOP does. --- src/lib/ps-macro-lib.lisp | 7 +++++-- 1 files changed, 5 insertions(+), 2 deletions(-) diff --git a/src/lib/ps-macro-lib.lisp b/src/lib/ps-macro-lib.lisp index e6c32be..85a55ea 100644 --- a/src/lib/ps-macro-lib.lisp +++ b/src/lib/ps-macro-lib.lisp @@ -137,10 +137,13 @@ `((@ ,fn :apply) this ,arglist))) (defpsmacro destructuring-bind (vars expr &body body) - ;; a simple implementation that for now only supports flat lists + ;; a simple implementation that for now only supports flat lists, + ;; but does allow NIL bindings to indicate ignore (a la LOOP) (let* ((arr (if (complex-js-expr? expr) (ps-gensym) expr)) (n -1) (bindings (append (unless (equal arr expr) `((,arr ,expr))) - (mapcar (lambda (var) `(,var (aref ,arr ,(incf n)))) vars)))) + (mapcan (lambda (var) + (incf n) + (when var `((,var (aref ,arr ,n))))) vars)))) `(let ,bindings ,@body))) -- 1.6.1

1 0

[parenscript-devel] Bug: latest PS breaks some conditional expressions
by Daniel Gackle 09 May '09

09 May '09

I'll use SETF to force PS to interpret the right-hand side as an expression. These are correct: (ps (setf x (let ((a 1)) a))) => "x = (a6872 = 1, a6872);" (ps (setf x (unless (null a) (1+ a)))) => "x = a != null ? a + 1 : null;" But this is wrong: (ps (setf x (let ((a (foo))) (unless (null a) (1+ a))))) => "x = (a6874 = foo(), if (a6874 != null) { a6874 + 1; });" Daniel

2 1

[parenscript-devel] ps-compile-file and eval-when, patch included
by Red Daly 29 Apr '09

29 Apr '09

I have had Parenscript file compilation working in a local version of Parenscript for a long time, but this feature is still missing from the official Parenscript. It seems like a logical feature to place into the main Parenscript project. Parenscript is useful for creating large Javascript applications and where there are large software projects there is a need for files. Some Parenscript interacts with Lisp code, but other Parenscript is written purely for the front-end. This sort of code belongs in a standalone Parenscript file. A naiive file compiler for Parenscript looks like this: (defun ps-compile-file (source-file) (with-open-file (input source-file :direction :input) (let ((end-read-form '#:unique)) (flet ((read-form () (read input nil end-read-form))) (do ((form (read-form) (read-form)) (forms nil)) ((eql form end-read-form) (ps:ps* `(progn ,@(nreverse forms))))))) However, just as in Lisp, it is helpful to have a little more control when compiling files than just creating a PROGN with the form and compiling as if it were any other code. It is useful to have EVAL-WHEN forms to manipulate the reader and so on. Therefore I have added the idea of top-level forms, including the EVAL-WHEN special form, to address this issue. EVAL-WHEN in Parenscript is similar to EVAL-WHEN in lisp but it takes into account the fact that when compiling the relevant language is LISP, but when executing the relevant language is Parenscript. An example of using EVAL-WHEN to define an IN-PACKAGE macro to manipulate the reader: (defpsmacro in-package (package-designator) `(eval-when (:compile-toplevel) (setf cl:*package* (find-package ,package-designator)))) Attached is a patch against the current git repository with this change and another bug fix. Best regards, Red

2 1

[parenscript-devel] Bug in composed conditional expressions
by Daniel Gackle 29 Apr '09

29 Apr '09

I'm seeing a bug in how conditionals are grouped together. (ps (return (if (if x y z) a b))) => "return x ? y : z ? a : b;" This requires parentheses in order to evaluate the way the PS expression was clearly intended, namely: (x ? y : z) ? a : b PS appears to make the wrong decision about when to include parentheses, since it does it here when the default would do: (ps (return (if x y (if z a b)))) => "return x ? y : (z ? a : b);" Daniel

2 1