Yes, that's it. Sorry for the ambiguity. I actually rely on this behavior
in more than one place; it basically gives you #DEFINE for magic 
numbers.

Thanks,
Dan

On Thu, Sep 13, 2012 at 7:40 PM, Vladimir Sedach <vsedach@gmail.com> wrote:
Do you mean something like this:

(symbol-macrolet ((x 1))
    (let ((blah 1))
     (case blah
       (0 3)
       (x 7)
       (t 13))))

Where the key x is supposed to expand to 1? In CL that code evaluates
to 13, but since there's no way symbols can be used as keys I suppose
using symbol macros that expand to numbers makes a lot of sense.

Let me know if the above example is the behavior you think should be
provided (ie the form should return 7), and I'll make a patch.

Vladimir

On Thu, Sep 13, 2012 at 10:15 PM, Daniel Gackle <danielgackle@gmail.com> wrote:
> Trying to upgrade to the latest PS, I have a problem with this CASE fix:
> it rejects symbol macros that expand to numbers. It's quite handy to
> use symbol macros this way for compile-time constants, so I hope
> the desired behavior can be restored.
>
> Daniel
>
>
>
> On Mon, Sep 3, 2012 at 7:22 PM, Vladimir Sedach <vsedach@gmail.com> wrote:
>>
>> This I would definitely call a bug. Since the position PS takes right
>> now is that it doesn't have symbols as run-time objects, I made the
>> decision to disallow them as keys in CASE clauses. Only keyword
>> symbols (which are translated to strings), numbers and string literals
>> are allowed.
>>
>> The behavior exhibited in your case is perfectly ok JavaScript though,
>> so the SWITCH special form still supports having variables and others
>> things as keys.
>>
>> I made a note in the reference manual (in the repo, I'll update the
>> version on the PS website with the next release), and also fixed some
>> other bugs I found in CASE and SWITCh statements.
>>
>> Thank you for bringing this issue up!
>>
>> Vladimir
>>
>> On Mon, Sep 3, 2012 at 8:09 AM, Boris Smilga <boris.smilga@gmail.com>
>> wrote:
>> > Hello.
>> >
>> > I've noticed that Parenscript has a different semantics from Lisp as
>> > regards keys of CASE clauses.  Lisp assumes an implicit QUOTE in this
>> > context, so that a symbol used as CASE clause key matches a test-key
>> > which is EQL to the symbol, as opposed to its value.  Parenscript, on
>> > the other hand, translates CASE forms to switch statements where
>> > symbol keys are used as identifiers.  E. g.
>> >
>> >   (let* ((foo 'bar) (bar 'foo) (x bar))
>> >     (case x ((foo) 1) ((bar) 2)))
>> >
>> > translates to
>> >
>> >   (function () {
>> >       var foo = 'bar';
>> >       var bar = 'foo';
>> >       var x = bar;
>> >       switch (x) {
>> >       case foo:
>> >           return 1;
>> >       case bar:
>> >           return 2;
>> >       };
>> >   })();
>> >
>> > Note that the former evaluates to 1, the latter to 2.
>> >
>> > Now, is this a bug, or a feature?  The section on CASE in the
>> > Parenscript Manual is actually misleading, whatever the answer.
>> >
>> >  — B. Smilga.
>> >
>> > _______________________________________________
>> > parenscript-devel mailing list
>> > parenscript-devel@common-lisp.net
>> > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
>>
>> _______________________________________________
>> parenscript-devel mailing list
>> parenscript-devel@common-lisp.net
>> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
>
>
>
> _______________________________________________
> parenscript-devel mailing list
> parenscript-devel@common-lisp.net
> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
>

_______________________________________________
parenscript-devel mailing list
parenscript-devel@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel