I think my concept is more robust and any boolean test can be used.

Sometimes less is more.

use strict;
use warnings;

use Data::Dump;


{
    my %state;

    sub till {
        my @phases=@_;
        #dd \@_;
        my ($file,$line)= (caller)[1..2];
        my $state = \$state{$file,$line};
        $$state //= 0;
        $phases[1+$$state]->();
        if ($phases[$$state]) {
            $$state += 2;
            $$state %= @phases;
        }
    }
}


while (my $var = <DATA>){
    till (
        - ($var =~ /for/)   => sub { print "*: $var" },
        - ($var =~ /their/) => sub { print "1: $var" },
        - ($var =~ /fruit/) => sub { print "2: $var" },
        - ($var =~ /lazy/)  => sub { print "3: $var" },
       );
}

__DATA__
now is the time
for all good men to
come to the aid of
their party.
Time flies like an arrow
fruit flies like a  banana.
The quick red fox
jumps over the lazy
brown dog.
Etaoinshrdlu.
[download]

out

*: now is the time
*: for all good men to
1: come to the aid of
1: their party.
2: Time flies like an arrow
2: fruit flies like a  banana.
3: The quick red fox
3: jumps over the lazy
*: brown dog.
*: Etaoinshrdlu.
[download]

¹) What if a test returns a reference for true? Enforcing negation with a unitary minus solves this issue.

(Updated to add explanation of the error in the scalar test.)

I added tests for code references and scalars as conditions:

sub c3 { print "Evaluating condition 3\n"; /gamma/; }
sub c4 { print "Evaluating condition 4\n"; /omega/; }

while (<DATA>) {
    chomp;
    mff(qr/alpha/ => \&s1,
        qr/beta/  => \&s2,
        \&c3      => \&s3,
        c4()              ) or print "*:$_\n";
}
[download]

In the above, a code ref to c3 is passed. c4, however, is called and its result, a scalar, is passed.

The results:

Evaluating condition 4
*:This is
Evaluating condition 4
1:the alpha
Evaluating condition 4
1:but not
Evaluating condition 4
1:the omega
Evaluating condition 4
2:Now the beta
Evaluating condition 4
Evaluating condition 3
2:progressing to
Evaluating condition 4
Evaluating condition 3
*:the gamma
Evaluating condition 4
*:and finally
Evaluating condition 4
*:the omega
Evaluating condition 4
*:Did this work?
[download]

c3, which was passed as a code ref, was evaluated only in state 2, as expected. So, conditions passed as code refs do work.

c4, because it is called before calling mff, is evaluated every iteration, as expected. However, there is an error: mff transitioned to the "inactive" state too soon.

Update: changing the call to c4 to !!c4() "fixed" the test. The !! imposes scalar context on the call to c4. (It also "imposes" boolean context. Note that +c4() or -c4() would also have worked.)

Note: LanX raises a valid point: "What if a test returns a reference?" That depends on what the reference points to. If a scalar, then the scalar value is tested. If a regex, it is evaluated against $_. If code, it is evaluated and its return value tested. If another reference, that reference is treated as a scalar.¹ If anything else, mff croaks with the message "Unsupported type".

I think flip-flop ( .. ) handles refs to scalars, regexen and code the same. Given that ref(ref(any)) eq 'SCALAR', I suspect it handles refs to refs the same as scalars. Refs to anything else, I don't know. More testing needed.

---

¹ I tested print ref(ref(1)) and print ref(ref(qr/foo/)) and print ref(ref(sub { print 1; })) and several others. Each time, the result was SCALAR

Keys are always a stringifyed!

I added a "code ref" test:

sub c3 { print "Evaluating condition 3\n"; /gamma/; }

while (<DATA>) {
    chomp;
    mff(qr/alpha/ => \&s1,
        qr/beta/  => \&s2,
        \&c3      => \&s3,
        qr/omega/         ) or print "*:$_\n";
}
[download]

The output:

*:This is
1:the alpha
1:but not
1:the omega
2:Now the beta
Evaluating condition 3
2:progressing to
Evaluating condition 3
3:the gamma
3:and finally
*:the omega
*:Did this work?
[download]

Which is what I expected.

Apparently, the "fat comma" ( => ) only quotes bare words. chromatic claims the same in the first paragraph of http://www.modernperlbooks.com/mt/2013/04/the-fat-comma-and-clarity.html.

So, => is not imposing string context on \&c3 so that doesn't get stringified.

ah yes right!

The trap was that hash keys are always strings, but while the arguments look like a hash structure they aren't real keys and values.

I remember now that I fell into this trap before...

But still, when passing values which are supposed to be boolean it's safer to negate them.

Cheers Rolf

_{(addicted to the Perl Programming Language and ☆☆☆☆ :)}