Ok, I pushed a patch. Let me know if that works ok. Vladimir
On Thu, Sep 13, 2012 at 10:52 PM, Daniel Gackle <[email protected]> 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 <[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 > _______________________________________________ parenscript-devel mailing list [email protected] http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
