[parenscript-devel] Another CASE fall-through bug

[Vladimir Sedach]

Yes, this was a bug in the way case vs if was handled. Just pushed a fix.

Thanks,
Vladimir

2011/2/2 Daniel Gackle <danielgackle at gmail.com>:
> The recent bug fixes seem to have worked (thanks). It seems
> I can't remove my warning-silencing workaround code, though (hacking
> *defined-operators*). I mention this because it's not clear to me if the
> intention was to not need that workaround anymore. What should the
> current behavior be - you get a warning if you redefine a built-in operator,
> but not an error?
> I did encounter a new problem while removing other workarounds.
> At least I think it's a new problem rather than a failure to fix
> the related earlier bug - I'm not really sure.
> This incorrectly falls through to the 456 case when foo1() returns
> true and foo2() does not. The example can probably be pared down
> further, but I don't have time to make it shorter.
>
> (defun blah (x)
>   (case x
>     (123
>      (cond ((foo1)
>             (when (foo2)
>               (when (foo3)
>                 (return-from blah nil))
>               t))))
>     (456 (foo7))))
> function blah(x) {
>     switch (x) {
>     case 123:
>         if (foo1()) {
>             if (foo2()) {
>                 if (foo3()) {
>                     return null;
>                 };
>                 return true;
>             };
>         };
>     case 456:
>         return foo7();
>     };
> };
> _______________________________________________
> parenscript-devel mailing list
> parenscript-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
>
>