Since regular expressions evaluate to values [that's what makes them expressions], type theory is perhaps a better abstraction than set theory. In particular, since regular expressions accept an input and produce an output, it May be particularly useful to think of them as function types.
If PIRE is an ancestor type of Perl regular expressions, then it's less specific input language can be fed into a Perl engine and Perl's more specific input language cannot be fed into it. Compatibility/incompatibility labels depend on which side of covariance/contravariance [1] the person doing the labeling stands. The authors of the library got their labelbaby label maker out first.
If they were wrong, file an issue on their Github repository.
Regular Expressions define/describe a language. They do not, can not, evaluate to a value, and it wouldn't even make sense if they did.
Regular Expressions also don't by themselves accept input. A RE library/software accepts input (which is always a finite string, an expression (also a finite string), and always returns one of two values: The input string is a member of that language, or the input string is not a member of that language. The result is binary, and it isn't returned from the regular expression.
Saying that you can't feed PCRE expressions into PIRE is completely false, since my original comment and the example in the linked github is literally a valid PCRE. That's like saying ASM.js isn't compatible with JavaScript, which is obvious nonsense, because it's by definition a strict subset of javascript.
The set of all regular expressions that will test valid in this library is strictly a subset of those which are valid in PCRE.
Type theory has nothing to do with anything here, and even if it did, PCRE and PIRE have identical functional types. They both accept string expressions (language descriptions), finite string input, and they both return boolean values (wether the input string is a member of that language).
And enough with the snark already. You aren't the only one on the planet who knows what a DFA/NFA is, and your statements make it seem debatable that you understand them.
But again, my first question was: "is this name really a joke?", which could have been answered by a single damned comment saying "yes".
When we get to the end of a string, the automata is either in an accepting state or not. If that ain't a boolean, it'll do till one comes along...at least for me as I have a hard time imagining uses for regular expressions that aren't implemented so as to return values. Then again I'm not that bright and tend to mumble along writing down my thoughts.
Which is why I'm writing about types...it seems to unroll the at hand possible "compatible/incompatible" conundrum of the name...or at least when after writing about it and heaedd to bed, I realized a simpler illustration was possible using Sets...and isn't that just the way of the maths, one description is isomorphic with another that makes explanation easier? Alas, I despaired of sharing it, but then this very morning I found a place for it.
Anyway, if one tests for compatibility [whatever that may be] between a set S and a superset SS as suggested above, the results of the test depend on both the test chosen and the ordering of the arguments. This is to say:
For each m in S, m is member of SS -> true
For each mm in SS, mms is member if S -> false
But choosing a different test
S is subset of SS -> true
SS is subset of S -> false
Of course whether we map true to compatibility [whatever that is] or incompatibility is entirely dependent in our arbitrary choice of whether our test is deemed to be for compatibility or incompatibility.
I wish I had an easy answer, but it's turtles, even by any other sweet smelling name, all the way down I'm afraid.
