That's (a) an awfully counterintuitive interface, though I did eventually figure it out, (b) still pretty darned cool, but (c) falls so far short of what I usually need when I have to think more than two seconds about an RE that I wonder whether I've been using the wrong tools for a while and need to finally get around to finding out what lexx and yacc do. (If that RE tool had a button for "the pitch part of a note in ABC syntax" or "a complete ABC note with or without all the optional components", that'd be helpful -- and that can be done with an RE -- but I guess that's really more of a write-a-parser situation than a write-a-RE situation.) I guess the author has done me a service by making it easier for me to see that, even if I'm not the right audience for that particular tool.
f?lex is a glortified RE matcher that generates C. (glortified sounds better than glorified. Or maybe it's been one of those days.
yacc/bison s a context-free LL(k) grammar parser.
They generate C files (last I checked, C++ support was experimental). You inline code in both to generate a your own parse tree, which you then hand off to your code when the flexible bison finishes with it.
They are a fairly heavyweight solution. For lightweight parsing, I prefer Parse::RecDescent in CPAN.
Oh, if you have any questions about parsing, I am glad to give you an answer, provided an occasional "Huh, that's interesting" is okay.
/csgeek
Edited (glarg, " changes meaning of things) 2011-04-19 04:08 (UTC)
I may take you up on that, once I get around to looking in detail at what those tools will and won't do for me. I do have a tendency to push things kind of far with sed -- my gut instinct whenever an RE situation comes up and it's not in an interactive editing session, is to say, "Oh, just run it through sed; that's what pipelines are for." Or worse yet, "It's late and I always screw something up when I try to use sscanf() -- screw it, pipe it through sed, dc, sort, and then sed again, and I won't even try to capture anything until all the math is already done. This works disgustingly often, but as I get farther from "grab the nth space-delimited word" or "extract columns n through m" and more into "insert this token after the first of this type of token that has these allowable forms and before the next of that other type of token that has eight optional constituent parts I might have to recognize" territory, my sed scripts are getting longer and I start thinking "maybe I should treat this grammar as, like, a grammar someday".
But no, I'm not sure I'm actually into 'heavyweight' parsing yet. (I'm not sure where the line is generally considered to be, but I tend to categorize problems as "my first thought before serious analysis was to use sed," and "my first thought before serious analysis was that I'd wind up writing a state machine". I'm thinking heavyweight would be, "yeah, I can do this with my old tools but it's not gonna be fun.") Hmm.
You've probably guessed by now that I'm not using Perl much, because I probably wouldn't be reaching for sed and dc as often if I were.
I mean, it's massively cool from a theoretical POV, but If I can't do it in a few blobs of re, more re won't help, and I go to my trusty ifs/whiles/etc.
![[staff profile]](https://www.dreamwidth.org/img/silk/identity/user_staff.png){kind=small}
![[site community profile]](https://www.dreamwidth.org/img/comm_staff.png){kind=small}
no subject
no subject
no subject
What, no sed/vi/vim/ex language button?
Re: What, no sed/vi/vim/ex language button?
yacc/bison s a context-free LL(k) grammar parser.
They generate C files (last I checked, C++ support was experimental). You inline code in both to generate a your own parse tree, which you then hand off to your code when the flexible bison finishes with it.
They are a fairly heavyweight solution. For lightweight parsing, I prefer Parse::RecDescent in CPAN.
Oh, if you have any questions about parsing, I am glad to give you an answer, provided an occasional "Huh, that's interesting" is okay.
/csgeek
Re: What, no sed/vi/vim/ex language button?
But no, I'm not sure I'm actually into 'heavyweight' parsing yet. (I'm not sure where the line is generally considered to be, but I tend to categorize problems as "my first thought before serious analysis was to use sed," and "my first thought before serious analysis was that I'd wind up writing a state machine". I'm thinking heavyweight would be, "yeah, I can do this with my old tools but it's not gonna be fun.") Hmm.
You've probably guessed by now that I'm not using Perl much, because I probably wouldn't be reaching for sed and dc as often if I were.
Re: What, no sed/vi/vim/ex language button?
Here's a problem sample that requires parsing - say you want to write a program that does a call graph of perl.
Program goes in, graph that tracks what function calls what comes out.
You can't explain that with regex alone.
FWIW, it's a mildly annoying problem i need to solve one of these days. Last run I took at it left me bleeding in the lambda and class methods.
no subject
no subject
no subject
no subject
I think it might be useful, sometimes?
I mean, it's massively cool from a theoretical POV, but If I can't do it in a few blobs of re, more re won't help, and I go to my trusty ifs/whiles/etc.