The London Perl and Raku Workshop takes place on 26th Oct 2024. If your company depends on Perl, please consider sponsoring and/or attending.




    use FP::Predicates;

    is is_string("Hi"), 1;
    is is_string(["Hi"]), 0;
    use FP::List; use FP::Equal 'is_equal';
    is_equal list(1, 2, 3, 0, -1, "hi", [1])->map(\&is_natural0),
             list(1, 1, 1, 1, 0, 0, 0);

    package Foo {
        use FP::Predicates;

        *is_age = both \&is_natural0, sub { $_[0] < 130 };
        # ^ if you do not want this to show up as a method,
        #   wrap it in BEGIN { } to get deleted in FP::Struct's
        #   namespace cleaning step; or assign to a scalar instead (my
        #   $is_age), of course; or use an inline expression (second
        #   line below)

        use FP::Struct [[\&is_string, "name"], [\&is_age, "age"]];

        # use FP::Struct [[\&is_string, "name"],
        #                 [both (\&is_natural0, less_than 130), "age"]];


    is (Foo->new("Moo", 13)->age, 13);

    # Experimental:
        use FP::Failure '*use_failure';
        local $use_failure = 1;

        my $isp = is_pure_class("FP::Array");
        is $isp ? "yes" : "no", "no";
        is $isp->message,
           "failure: is_pure_class: 'FP::Array'\n";
        is is_pure_class("FP:: Array")->message,
           "failure: is_pure_class\n".
           "  because:\n".
           "  failure: is_valid_class_name: 'FP:: Array'\n";


Useful as predicates for FP::Struct field definitions.

These are simple functions expecting one value and returning a boolean. They are composable with `maybe`, `complement`, `either`, `all_of`/`both`.

This is a functional approach to achieve the same aim as `Moose::Util::TypeConstraints`, which basically uses a syntactical sublanguage instead (implemented as a mix of functions and string interpretation). It was written because it's way simpler. The drawback is that (currently) there's no way to get a nice message string from them to say why a match fails. Perhaps it would be possible to do so using more introspection? (That would be nice because message generation would be fully automatic and hence consistent.) Or, alternatively, modifying the functions to compose messages themselves when they fail (still mostly automatic), e.g. using message objects that are false.


This is alpha software! Read the status section in the package README or on the website.