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

[parenscript-devel] Operator precedence bug
by Daniel Gackle 25 Apr '10

25 Apr '10

Overzealous parenthesis removal: (ps (- x (- a b))) => "x - a - b;"

2 1

[parenscript-devel] !== doesn't work anymore
by Daniel Gackle 24 Apr '10

24 Apr '10

Working my way through some more compilation issues with the latest PS, I noticed this: (ps (!== x)) => "bangequalsequals(x);" Is !== deprecated? If so, it should issue the usual warning. On a related note, I get a bunch of warnings about % being deprecated in favour of REM, which is fine, but I can't actually find the usages in my code. Grep doesn't help. They must be implicit somehow. I wonder if it would be a good idea for the deprecate warning to print the offending form? Daniel

2 1

[parenscript-devel] logical operator bugs
by Daniel Gackle 22 Apr '10

22 Apr '10

I was glad to see LOGAND, LOGIOR, and LOGXOR added to PS, because it means we can remove these from our macro library. However, they don't work with assignment statements. For example, the following form crashes: (ps (setf x (logand x y))) Daniel

1 1

[parenscript-devel] Equality issues
by Daniel Gackle 22 Apr '10

22 Apr '10

The array literals fix worked, thanks. Next up: the changes around equality are a problem. Specifically, the NULL operator, which used to evaluate to true on both null and undefined, now applies strict equality, meaning that (null undefined) is false. Since we use the NULL operator in a great many places precisely to check whether something is null or undefined, this change breaks our code. In general, I've found it to be good to conflate null and undefined in most of our PS code; it simplifies things and works fine. So I guess we have to go on record as protesting this change... especially since there already existed ways to distinguish null from undefined in the minority case when it's needed. Others' thoughts? Dan p.s. I haven't looked closely at the other implications of the equality changes, because the NULL issue is such a big one that I thought I'd start there.

2 5

[parenscript-devel] Lexical scoping bug
by Daniel Gackle 21 Apr '10

21 Apr '10

Just ran across this one: (ps (let ((abc (@ x :abc))) (funcall abc))) => "var abc901 = x.abc; abc();" Daniel

5 13

[parenscript-devel] % is broken (was: Equality issues)
by Daniel Gackle 21 Apr '10

21 Apr '10

I see the null fix, and the other equality stuff looks right so far, but I can't give a complete answer about that yet; our code won't run because the % operator is broken. (ps (% a b)) => "percent(a, b);" Daniel On Tue, Apr 20, 2010 at 3:43 PM, Vladimir Sedach <vsedach(a)gmail.com> wrote: > You're right, that absolutely makes sense. I've pushed a fix. > > It's interesting to note that this is the only place in the code > Parenscript generates where the semantics of '==' (as opposed to > '===') make sense. > > Vladimir > > 2010/4/19 Daniel Gackle <danielgackle(a)gmail.com>: > > The array literals fix worked, thanks. Next up: the changes around > equality > > are a problem. > > Specifically, the NULL operator, which used to evaluate to true on both > null > > and undefined, now applies strict equality, meaning that (null undefined) > is > > false. Since we use the NULL operator in a great many places precisely to > > check whether something is null or undefined, this change breaks our > code. > > In general, I've found it to be good to conflate null and undefined in > most > > of our PS code; it simplifies things and works fine. So I guess we have > to > > go on record as protesting this change... especially since there already > > existed ways to distinguish null from undefined in the minority case when > > it's needed. > > Others' thoughts? > > Dan > > p.s. I haven't looked closely at the other implications of the equality > > changes, because the NULL issue is such a big one that I thought I'd > start > > there. > > _______________________________________________ > > parenscript-devel mailing list > > parenscript-devel(a)common-lisp.net > > http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel > > > > > > _______________________________________________ > parenscript-devel mailing list > parenscript-devel(a)common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel >

2 1

[parenscript-devel] Array literals broken in latest commit (514d022)
by Daniel Gackle 19 Apr '10

19 Apr '10

The problem with mult is fixed (thanks!). The next problem I've encountered is that array literals no longer work. The previous behavior was: (ps #(2 3)) => "[2, 3];" This now crashes. Daniel

2 1

[parenscript-devel] Patch: added .gitignore to ignore fasls
by Daniel Gackle 09 Apr '10

09 Apr '10

I just pushed a patch (authored by Scott) to add .gitignore to the PS project so that fasls can be ignored. This is because, if you're using git submodules with PS, git thinks the library has changed every time you recompile it, unless you explicitly tell it to ignore fasls. Git submodules aren't particularly simple, but we use them for one huge benefit: it lets git track which version of PS goes with which version of our code. So if we need to restore our system of a month ago, and there have been a bunch of patches to PS in the last month, git will check out the old version of PS that's contemporary with the old version of our stuff. This solves the huge headache of trying to run an old version of your code against newer versions of its libraries, which works until it doesn't and then is hard to track down. I'd be interested if anyone has a better solution to this problem, because I'm not fond of git submodules, but am willing to live with them to get the above. Daniel

2 1

[parenscript-devel] Bug with ==
by Daniel Gackle 11 Mar '10

11 Mar '10

(let ((x 10) (y 10) (z 10)) (= x y z)) is true Common Lisp, but the PS equivalent... var x = 10; var y = 10; var z = 10; x == y == z; ... is false. The left operand of the second == is actually x==y, which evalutes to true, and true==z of course is false. An equivalent in CL might be: (equal (equal x y) z) Perverse side note: the above example doesn't work if you assign 1 to the variables because in JS, the following is true: 1 == true I didn't know this. JS still manages to shock me sometimes. Daniel

4 4

[parenscript-devel] A PS version of NCONC
by Daniel Gackle 09 Mar '10

09 Mar '10

I needed a destructive append to a JS array, so I wrote this version of NCONC for PS. It's primitive, but does what I need. (defun nconc (arr &rest arrs) (when (and arr (> (length arr) 0)) (loop :for other :in arrs :when (and other (> (length other) 0)) :do ((@ arr :splice :apply) arr (append (list (length arr) (length other)) other)))) arr) I suppose this would naturally go in some kind of runtime library for PS. (We have quite a few utility functions that might belong there, in fact.) But I don't think there is one anymore. Should there be? Daniel

4 4