in reply to Re^4: No braces
in thread No braces

Point taken. Looking over CPAN right now, it appears Damian wrote a Switch module. I really wish something like this was in the core distribution. Well, I guess we can wait a few years for Perl 6! Anyone have experience with this?

See below. I have done something like this before and didn't like it much, but it got the job done. Really though, it's not any cleaner than the if-comb due to the extra semantic gorp. 

    foo: {
        if (/^abc/) { $abc = 1; last foo; }
        if (/^def/) { $def = 1; last foo; }
        if (/^xyz/) { $xyz = 1; last foo; }
        $nothing = 1;
    }

[download]

Replies are listed 'Best First'.
Re^6: No braces
by hardburn (Abbot) on Feb 11, 2004 at 15:26 UTC

    Damian's Switch.pm relies on source filtering, which means that unless it can parse Perl perfectly (ha ha!), you'll get bugs in portions of code that having nothing to do with switches just because you included use Switch; in your code. So it shouldn't be used in any practical code.

    One of the advantages of a C-style switch is that it gives you O(1) efficiency in going through the cases, whereas all Perl idioms for emulating it have a O(n) worst case (or all cases, if you don't include a last to break the switch. This was discussed at Re: Perl Idioms Explained: && and || "Short Circuit" operators.

    Note that neither Switch.pm nor Perl6 switches offer O(1) efficiency, since they can't be implemented using jump tables like C switches are. For that, you need to use a dispatch table using hashes holding references to subroutines (super search for "dispatch table" should give interesting results).

    ----
    : () { :|:& };:

    Note: All code is untested, unless otherwise stated

[reply]
[d/l]
[select]
      Note that neither Switch.pm nor Perl6 switches offer O(1) efficiency, since they can't be implemented using jump tables like C switches are. For that, you need to use a dispatch table using hashes holding references to subroutines (super search for "dispatch table" should give interesting results).
      This is true of Switch.pm but untrue of Perl 6 switches, which are expected to pay sufficient attention to the syntax that if you use constants it will recognize that it can optimize it to a jump table. In general, the compiler is perfectly free to jump over any cases that it knows will never be true. Even when the values aren't constants, you can tell the compiler to treat them a particular way by using an appropriate context operator such as + or ~.

      Update: I forgot to mention that Perl 4 already does this optimization. It never got into Perl 5 due to a lack of tuits, however.

[reply]
[d/l]
[select]
      Damian's Switch.pm relies on source filtering, which means that unless it can parse Perl perfectly (ha ha!), you'll get bugs in portions of code that having nothing to do with switches just because you included use Switch; in your code. So it shouldn't be used in any practical code.
      I don't agree with that. It's an argument against editor filters for colouring text - they either have to be perfect for any text thrown at them, or you have to suffer the consequences. A source filter is fundamentally different. There you apply a filter to a program. And then you run your tests. If the filter works, you're done. Otherwise, you tune your filter and/or your program until it works. (But usually, the filter will work the first time).

      Abigail

[reply]

        Editors don't have to be perfect at coloring text, because the worst that can happen is that the colors are wrong when you view the source--it's annoying, but I can live with it. In the case of Switch.pm, anything other than parsing code exactly the way perl does is unaccaptable, because anything less will cause bugs, often in areas which are unrelated to the use of a switch. There are a few source filters which don't have to be perfect because they're doing very simple things (Acme::Bleach comes to mind), but Switch.pm isn't one of them.

        ----
        : () { :|:& };:

        Note: All code is untested, unless otherwise stated

[reply]
[d/l]
      "Damian's Switch.pm relies on source filtering, which means that unless it can parse Perl perfectly (ha ha!), you'll get bugs in portions of code that having nothing to do with switches just because you included use Switch; in your code. So it shouldn't be used in any practical code."

      This is true. I naively tried to use Switch once upon a time, because I like that construct, in some software that I was writing and it seriously broke my code. I had obscure error messages that were nearly impossible to debug until I realized that Switch was the culprit.

      I agree. Don't use Switch unless you want to court devious Perl bugs.

      metadoktor

      "The doktor is in."

[reply]

      The requirements for the module did seem to imply a potential performance hit, true.

      Source filtering is not the way I'd like to see a language extended.

      Your jump-table description does make sense to me. This is why switch statements only accept constants ... they are not evaluating if-tests. That makes it very clear, appreciate the explanation, sort of a "a ha! that explains it!" kind of feeling after using switches for so many years.

[reply]

In Section Meditations