You're right it is. Where we differ is that your Array::PatternMatcher separates extractions from assertions and only borrows from the regex syntax. It's the sort of thing that we all know full well can be implemented by adding code. I'm looking at it sort of like exchanging m/^\d+$/ for sub is_numeric { for (split //) { return unless ord($_) >= ord('0') and ord($_) <= ord('9') } return 1 }. Or at least that's how it looks on the surface after reading your POD once.
I'm just thinking it'd be a big win to be able to specify regular expressions in more than one dimension. Following on my original meditation I think perhaps I mislead myself. I think the proper multi-d regex is only going to have a new operator such that it tells the engine to go perpendicular and in which direction. A 2-d example would be an instruction to turn right at a certain point. 3-d might mean to start going up. I think the rest of the meaning makes the most sense when you think of multi-d as a tangled one-d space. A normal regex already goes one character/byte at a time, there's no reason to drop that (and that is what I originally proposed with the idea of skipping around). So maybe that means giving the \[{dimension,direction} sequence *just* a dimension and direction parameter.
Initially I thought I'd need to rebind the regular expression at will to hop around to different array elements. I think instead... maybe when the engine isn't doing a normal 1-d regex that it'd need to run custom code that isn't regex at all to follow the data around. So this brings up the question - I've not seen a Regex tokenizer around (not that I've looked that hard either). Maybe with one of those an a controlling function you could jump around, test atoms and when possible use the normal regex engine.
If this isn't clear then someone please let me know.
__SIG__
use B;
printf "You are here %08x\n", unpack "L!", unpack "P4", pack
"L!", B::svref_2object(sub{})->OUTSIDE;
| 