[parenscript-devel] CASE keys in Parenscript vs. Lisp

[Daniel Gackle]

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