Greb Lives.
https://github.com/hostilefork/greb
It's of course catastrophically slow as such utilities go. But, design first, then optimize.
I've started it off on the right foot, with a test. Not a complicated one...it just filters a pre-made list of filenames, and makes sure it gets the expected results:
So that shows it working on Mac, Linux, and Windows.
What's Next For Greb?
Rulesets coming from a file are clearly an important feature. So instead of:
cat data.txt | greb "your <rule> here"
You would want to say:
cat data.txt | greb %my-rules.greb
But what format would these rules files take? How do they separate defining rules from running rules? How do they do #include of other files for rules they use?
For instance, some-a: [some "a"] could mean "assign a block to represent the reusable SOME-A rule". Or it could mean "run the some combinator on the input looking for the letter a, and then store the result in the variable some-a".
When we write source code, we make that separation by having code outside of PARSE that assigns the rules, then inside the PARSE it's run. But greb is hiding the call to PARSE and making it implicit. So what's the limit of what a greb file does?
Maybe you define rules, and it checks to see if there's one called main... if there's not, you still have to provide a string of rule code to get it kicked off?
That's one question. But then, how would the binding work?
This first take on greb implementation shows that I don't try to BIND things like DIGIT and ALPHA, but rather slip them into the combinator set. That's actually how DESTRUCTURE works as well.
There's a lot which this seemingly-"simple" task points out about things we may not have elegant solutions for. So it's definitely worth looking at.
Anyway, it has been started!