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]

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

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.

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

"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."

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.