my @candidates = qw(z y a b c a d a e a f);

foreach my $question ('a', 'm') {

    if (do{{;grep {$_ eq $question ? do {print "Match\n"; last} : 0 }
                  @candidates}})
    {
    print "Found $question\n";
    }

}
[download]

Of course that really just uses grep for its side-effect, and you could just a little less twisted-brainedly say something like

foreach my $question ('a', 'm') {
    if ( sub { $_ eq $question and return 1 for @candidates; 0; }->() 
+) {
        print "Found $question\n";
    }
}
[download]

which is basically an inlined implementation of List::Util’s first.

Makeshifts last the longest.

Of course that really just uses grep for its side-effect
No, it uses the return value as well. The interesting thing is that last is interpreted as true.

---

Caution: Contents may have been coded under pressure.

EvanCarroll is right about the slight differences in the routines, so I commented out some things in code and made them both use the same array (note, I increased the number of elements to look for as well as the number of iterations for more meaningful results):

#!/usr/bin/perl -w
use strict;
use Benchmark qw(:all);

my @choices = qw|a b c z m p t l c f g|;

my %choices = map{$_=>1}@choices;

my @cData = <DATA>;

timethese(50_000,{'Damn Slow'=>\&parseData1,
                'Much Better'=>\&parseData2});

sub parseData1 {
foreach (@cData){
chomp;
my @items = split/,/,$_;
#slow way, 
foreach my $item (@items){
if(grep {$item eq $_} @choices){
   #print qq|FOUND $item|;
 } 
}

}
}

sub parseData2 {
 foreach(@cData){
 chomp;
# foreach my $item (split/,/,$_){
my @items = split/,/,$_;
#slow way, 
foreach my $item (@items){
    if ($choices{$item}){
       #print qq|FOUND $item\n|;
     }
   }
  }

}

__DATA__
z,t,m,u,a,b,c
s,t,l,m,z,a,s
c,b,a,m,u,t,n
k,l,t,s,z,r,t
[download]

Which still produces:

perl seediff.pl
Benchmark: timing 50000 iterations of Damn Slow, Much Better...
 Damn Slow:  6 wallclock secs ( 6.12 usr +  0.00 sys =  6.12 CPU) @ 81
+72.61/s (n=50000)
Much Better:  3 wallclock secs ( 2.96 usr +  0.00 sys =  2.96 CPU) @ 1
+6874.79/s (n=50000)
[download]

I think the above changes were 'fair' since the performance of a function like SQL in() in an actual database should not decrease noticeably with the number of elements.