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

[Vladimir Sedach]

> 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 sure whether it's better to classify this as a bug in CREATE.
The previous behavior was treating symbols as constants, except when
they had symbol macros associated with them. There's nothing wrong
with that behavior, but I'm not sure there are any other special forms
that do the same thing.

Vladimir

> 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
>
>
> _______________________________________________
> parenscript-devel mailing list
> parenscript-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
>
>