[parenscript-devel] Bug: Latest PS breaks how quoted symbols were handled before

[Daniel Gackle]

That is a good and unfortunate point you make.

I'm going to wait until the other bugs I posted have been fixed, then will
upgrade, revisit this issue and try to think of a workaround. I'd rather not
use strings for the operators, but perhaps keywords would do.

Regards,
Daniel

On Wed, May 6, 2009 at 3:48 PM, Red Daly <reddaly at gmail.com> wrote:

> On Wed, May 6, 2009 at 1:34 PM, Daniel Gackle <danielgackle at gmail.com>wrote:
>
>> One thing I forgot to point out: notice that, in the latest PS, the minus
>> operator '- is actually converted into an empty string in JS, which is
>> obviously wrong.
>>
>
>>
>> On Wed, May 6, 2009 at 2:27 PM, Daniel Gackle <danielgackle at gmail.com>wrote:
>>
>>> The latest PS interprets QUOTE of a symbol to mean, "first convert this
>>> symbol to a Javascript identifier, then a string". This breaks our code,
>>> because our formula parser relies on symbols to represent operators. Here's
>>> a line of code that PS was generating for us nicely before:
>>>
>>> (defparameter *op-symbols* '(| | + - * / ^ < > = <> <= >= & % ! { } [ ]
>>> |(| |)| |:| |,| |"| |'|))
>>> =>
>>> var OPSYMBOLS = [' ', '+', '-', '*', '/', '^', '<', '>', '=', '<>', '<=',
>>> '>=', '&', '%', '!', '{', '}', '[', ']', '(', ')', ':', ',', '"', '\''];
>>>
>>> In the new PS, it looks like this:
>>>
>>> var OPSYMBOLS = [' ', 'plus', '', 'star', 'slash', '^', '<', '>',
>>> 'equals', '<>', '<equals', '>equals', '&', 'percent', 'bang', '{', '}', '[',
>>> ']', '(', ')', 'colon', ',', '"', '\''];
>>>
>>> I think this is a mistake. The only reason for translating symbols like +
>>> to "plus" is if you want to use them in a JS identifier. But quoted symbols
>>> are not meant to turn into JS identifiers, only JS strings.
>>>
>>
>>> Looking at the git log, this change was introduced into
>>> special-forms.lisp by commit dd4442b8973fe8b2c19b44f94f244934aa418ae8. This
>>> was submitted at the time as a bug fix. From our point of view, this "fix"
>>> introduces a bug, and quite a serious one, since it means we can't run our
>>> formula parser (and a few other things) in the browser.
>>
>>
> The problem was that (slot-value object 'quoted-slot) had inconsistent
> semantics compared to other uses of quoted symbols.  This was fixed by
> making a quoted symbols behave as you describe: first convert this symbol to
> a Javascript identifier, then a string.
>
> For an example of where string-translation can go wrong, see this code:
>
> (let* ((our-slot 'foo-bar)
>          (val1 (slot-value object our-slot))
>          (val2 (slot-value object 'foo-bar))
>    ...)
>
> The fix made this code execute as you would believe it should: so that val1
> and val2 are equal.  If we were to translate symbols to their STRING-VALUE,
> val1 would = object["foo-bar"] and val2 would = object.fooBar.  That is,
> unless you change the semantics of slot-value.
>
> I am not sure what the context of your *op-symbols* code is, but it seems
> like you should be able to avoid this problem by using strings.  I don't
> know what the alternative is for the foo-bar example above, if we adopt a
> symbol translator like you suggest.
>
> Best,
> Red
>
>
>
>
>
>>
>> _______________________________________________
>> 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/20090507/3e4040dc/attachment.html>