parenscript-devel April 2010

parenscript-devel@common-lisp.net

6 participants
9 discussions

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

07 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] 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

parenscript-devel April 2010