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

[Daniel Gackle]

It did. Thanks!

On Thu, Sep 13, 2012 at 8:31 PM, Vladimir Sedach <vsedach at gmail.com> wrote:

> Ok, I pushed a patch. Let me know if that works ok.
>
> Vladimir
>
> On Thu, Sep 13, 2012 at 10:52 PM, Daniel Gackle <danielgackle at gmail.com>
> wrote:
> > 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
> >
> >
> >
> > _______________________________________________
> > 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/bd1d75b1/attachment.html>