Yes, that's it. Sorry for the ambiguity. I actually rely on this behavior<div>in more than one place; it basically gives you #DEFINE for magic </div><div>numbers.</div><div><br></div><div>Thanks,</div><div>Dan<br><br><div class="gmail_quote">
On Thu, Sep 13, 2012 at 7:40 PM, Vladimir Sedach <span dir="ltr"><<a href="mailto:vsedach@gmail.com" target="_blank">vsedach@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Do you mean something like this:<br>
<br>
(symbol-macrolet ((x 1))<br>
(let ((blah 1))<br>
(case blah<br>
(0 3)<br>
(x 7)<br>
(t 13))))<br>
<br>
Where the key x is supposed to expand to 1? In CL that code evaluates<br>
to 13, but since there's no way symbols can be used as keys I suppose<br>
using symbol macros that expand to numbers makes a lot of sense.<br>
<br>
Let me know if the above example is the behavior you think should be<br>
provided (ie the form should return 7), and I'll make a patch.<br>
<span class="HOEnZb"><font color="#888888"><br>
Vladimir<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Thu, Sep 13, 2012 at 10:15 PM, Daniel Gackle <<a href="mailto:danielgackle@gmail.com">danielgackle@gmail.com</a>> wrote:<br>
> Trying to upgrade to the latest PS, I have a problem with this CASE fix:<br>
> it rejects symbol macros that expand to numbers. It's quite handy to<br>
> use symbol macros this way for compile-time constants, so I hope<br>
> the desired behavior can be restored.<br>
><br>
> Daniel<br>
><br>
><br>
><br>
> On Mon, Sep 3, 2012 at 7:22 PM, Vladimir Sedach <<a href="mailto:vsedach@gmail.com">vsedach@gmail.com</a>> wrote:<br>
>><br>
>> This I would definitely call a bug. Since the position PS takes right<br>
>> now is that it doesn't have symbols as run-time objects, I made the<br>
>> decision to disallow them as keys in CASE clauses. Only keyword<br>
>> symbols (which are translated to strings), numbers and string literals<br>
>> are allowed.<br>
>><br>
>> The behavior exhibited in your case is perfectly ok JavaScript though,<br>
>> so the SWITCH special form still supports having variables and others<br>
>> things as keys.<br>
>><br>
>> I made a note in the reference manual (in the repo, I'll update the<br>
>> version on the PS website with the next release), and also fixed some<br>
>> other bugs I found in CASE and SWITCh statements.<br>
>><br>
>> Thank you for bringing this issue up!<br>
>><br>
>> Vladimir<br>
>><br>
>> On Mon, Sep 3, 2012 at 8:09 AM, Boris Smilga <<a href="mailto:boris.smilga@gmail.com">boris.smilga@gmail.com</a>><br>
>> wrote:<br>
>> > Hello.<br>
>> ><br>
>> > I've noticed that Parenscript has a different semantics from Lisp as<br>
>> > regards keys of CASE clauses. Lisp assumes an implicit QUOTE in this<br>
>> > context, so that a symbol used as CASE clause key matches a test-key<br>
>> > which is EQL to the symbol, as opposed to its value. Parenscript, on<br>
>> > the other hand, translates CASE forms to switch statements where<br>
>> > symbol keys are used as identifiers. E. g.<br>
>> ><br>
>> > (let* ((foo 'bar) (bar 'foo) (x bar))<br>
>> > (case x ((foo) 1) ((bar) 2)))<br>
>> ><br>
>> > translates to<br>
>> ><br>
>> > (function () {<br>
>> > var foo = 'bar';<br>
>> > var bar = 'foo';<br>
>> > var x = bar;<br>
>> > switch (x) {<br>
>> > case foo:<br>
>> > return 1;<br>
>> > case bar:<br>
>> > return 2;<br>
>> > };<br>
>> > })();<br>
>> ><br>
>> > Note that the former evaluates to 1, the latter to 2.<br>
>> ><br>
>> > Now, is this a bug, or a feature? The section on CASE in the<br>
>> > Parenscript Manual is actually misleading, whatever the answer.<br>
>> ><br>
>> > — B. Smilga.<br>
>> ><br>
>> > _______________________________________________<br>
>> > parenscript-devel mailing list<br>
>> > <a href="mailto:parenscript-devel@common-lisp.net">parenscript-devel@common-lisp.net</a><br>
>> > <a href="http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel" target="_blank">http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel</a><br>
>><br>
>> _______________________________________________<br>
>> parenscript-devel mailing list<br>
>> <a href="mailto:parenscript-devel@common-lisp.net">parenscript-devel@common-lisp.net</a><br>
>> <a href="http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel" target="_blank">http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> parenscript-devel mailing list<br>
> <a href="mailto:parenscript-devel@common-lisp.net">parenscript-devel@common-lisp.net</a><br>
> <a href="http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel" target="_blank">http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel</a><br>
><br>
<br>
_______________________________________________<br>
parenscript-devel mailing list<br>
<a href="mailto:parenscript-devel@common-lisp.net">parenscript-devel@common-lisp.net</a><br>
<a href="http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel" target="_blank">http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel</a><br>
</div></div></blockquote></div><br></div>