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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> > 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 <[email protected]> > >> 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 > >> > [email protected] > >> > > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel > >> > >> _______________________________________________ > >> parenscript-devel mailing list > >> [email protected] > >> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel > > > > > > > > _______________________________________________ > > parenscript-devel mailing list > > [email protected] > > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel > > > > _______________________________________________ > parenscript-devel mailing list > [email protected] > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel >
_______________________________________________ parenscript-devel mailing list [email protected] http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
