[parenscript-devel] Bug: lexical renames wrongly extended to CREATE special form

Daniel Gackle danielgackle at gmail.com
Wed Oct 14 18:08:21 UTC 2009


< so far I haven't been able to think of any cases where it would cause a
conflict. >

Interestingly, I just ran across such a conflict. I applied the fix in
68d111 (thanks), and discovered one thing that broke in our JS as a result.
It turns out that, in this one place, we do use a symbol macro as a property
name in a CREATE form. Something like this:

(ps (define-symbol-macro sym what-we-really-want))

(ps (create sym 123))
as of 68d111 => "{ sym : 123 };"
but should be => "{ whatWeReallyWant : 123 };"

I can change the code to not use a symbol macro that way. But at a deeper
level, it seems like if one is going to have symbol macros, they should work
here.

I'm not arguing for or against any particular implementation of lexical
scoping, but rather that such implementation details shouldn't percolate up
to the language level.


On Tue, Oct 13, 2009 at 10:14 AM, Vladimir Sedach <vsedach at gmail.com> wrote:

> > Lexical renaming is implementing in a very wrong way in the main
> > parenscript branch (by abusing symbol macros). I have introduced a
> > js:let syntax form and perform renaming at print time instead. The
> > implementation is significantly shorter and works for all cases.
>
> Have you run the PS unit tests on your branch? I just cloned your
> repository (up to patch faa26a99e6712), and it doesn't compile, but
> from looking at the code it would seem your changes wouldn't handle
> special variables, and maybe a few other things.
>
> I don't think there's anything wrong with using symbol-macrolet as the
> mechanism to implement renaming - so far I haven't been able to think
> of any cases where it would cause a conflict.
>
> Another thing I want to do is to make the PS printer take as input an
> s-expression representation of JavaScript - I'm working on a JS parser
> that will produce that representation as output, and a translator from
> the representation to CL. Eventually I want to take the printer out of
> Parenscript and move it into a separate project. So I'm a little
> against putting in non-JS constructs into the language that the
> printer understands.
>
> Vladimir
>
> > http://git.hcoop.net/?p=clinton/parenscript.git;a=summary
> >
> > --
> > Lindsay (Carlton): nighttime baker! sounds a little iffy
> >
> > _______________________________________________
> > parenscript-devel mailing list
> > parenscript-devel at common-lisp.net
> > http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
> >
>
> _______________________________________________
> parenscript-devel mailing list
> parenscript-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/parenscript-devel/attachments/20091014/a26bc0ca/attachment.html>


More information about the parenscript-devel mailing list