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

[Red Daly]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/parenscript-devel/attachments/20090506/d85e4f53/attachment.html>