[parenscript-devel] A class of bugs in PS: expressions not parenthesized when necessary
tc at travislists.com
Fri Nov 14 22:02:18 UTC 2008
I had a couple of fixes sitting in my repository that addressed some of
these issues. I've since pushed them up.
Daniel Gackle wrote:
> The following bug in PS broke my code today:
> (ps (aref (if (and x (> (length x) 0))
> (aref x 0)
> => "x && x.length > 0 ? x : y[z];"
This now returns:
(x && x.length > 0 ? x : y)[z];
> You can see a similar bug here:
> (ps (aref (or (slot-value x 'y)
> (slot-value a 'b))
> => "x.y || a.b[z];"
This now returns:
(x.y || a.b)[z];
> and here again:
> (ps (- (if x y z)))
> => "-x ? y : z;"
The changes I pushed didn't help that one. As I recall, that's actually
why I hadn't pushed them yet, because I wanted to look into the overall
precedence issue more thoroughly (but then of course, life refocused my
> Clearly, there's a problem with not parenthesizing things.
> Since the last patch or two I've sent have been ignored, I won't send a
> new one here, but rather ask: is PS being actively maintained or not?
> This project is too valuable to let fade.
Vladimir may be working on integrating your patches here and making
other changes in this area, so I won't step on his toes if that's the
case, except to push the fixes I'd already made.
Thanks for your continued interest in the project. You're quite right
that ParenScript is an important library that deserves better than the
off and on interest many of us can devote to it.
Long term I think the project should be able to take a more systematic
approach to supporting the ECMAScript standards. I think we can also
move towards doing more parse tree analysis in the compile step rather
than the simple translations we currently perform. I'd like to
implement such features as termination analysis to get rid of the need
for those ugly (return) statements, and perhaps add a way to unfold or
trampoline tail recursions.
More information about the parenscript-devel