Struggling again with these. I'm getting confused as to how many of the backslashes should be escaped. I'm trying to convert some like these from Perl, inside quotes:
With awk you can break it up into program steps. Better yet is to get rid of all those awful special characters in regular expressions. Here is a discussion of a possible LISPy way out of Perl/regex hell:
Hmm - some interesting musings there, but nothing practical or immediately useful. I'd rather struggle a bit with regular expression, imperfect though they may be, than completely fail in an attempt write a context-free grammar parser or whatever is needed.
Since I know you're using a Mac and Hans-Peter's recommendation runs on windows only, I'll mention my favorite regex helper: RegExhibt.
This is the fourth one I've tried so far, and I think this regex helper is head and shoulders above the others.
Also, if you will be doing a lot of regexing (or cssing, htmling, or even javascripting), I highly recommend The VisiBone Browser Book. I used this heavily during the edit of the newLISP manual and while making the neglOOk website. When I think how useful it's been to me, I'm sorry I didn't mention it earlier!
There are two-inch-thick books on the differences between the different regex flavors. PCRE is something of a standard, and that's the library newLISP uses. newLISP has better regex support than most other languages. The only thing it lacks is named groups, which I think were invented for Python and are not standard; but it does have recursion, I believe, using ?R syntax.
I usually put regular expressions between {} so I don't have to double-escape. Your expression should be able to be used verbatim between [text] tags (since it uses curly braces, curly braces would need to be escaped).
Jeff
=====
Old programmers don't die. They just parse on...
cormullion wrote:Struggling again with these. I'm getting confused as to how many of the backslashes should be escaped. I'm trying to convert some like these from Perl, inside quotes:
Holy Schneikees! What is *that* supposed to do? :-)
Seriously, whenever I write monstrosities like that, either I put a massive amount of comments explaining what each piece does, or I break up the regex string into smaller strings and assign them to meaningful symbol names (if only for my own benefit when I look at the code more than a week later). But you probably got this from non-cormullion code, right?
Sorry I can't help -- I always have to look it up in a book. I was doing OK until I got to (?s:.+?). :-)
Yes, horrible things. I think it was Markdown lists or headers I was trying to match. It's those positive and negative lookaheads that hurt my brain the most.
I had originally hoped to just copy these regexes without looking 'inside them', but they didn't work first time... And then you start tinkering with them, adding backslashes etc. and it all starts to come unstuck ;-(
Jeff wrote:Your expression should be able to be used verbatim between [text] tags (since it uses curly braces, curly braces would need to be escaped).
It's possible that curly braces might work - the manual quoth "Balanced nested curly brackets may be used within a string. This aids in writing regular expressions or short sections of HTML."
I might investigate, when I'm feeling more optimistic about regexes...
rickyboy wrote:
Holy Schneikees! What is *that* supposed to do?
Only a nitwit would write something like that or spend time figuring out what it did. I must say that the excessive use of macros in LISP is another example of this syndrome. I don't care how rich he is, Paul Graham is dead wrong.
Clear, concise, and simple is what I strive for. Complexity for its own sake is horse shit.
Jeff snipilly wrote:Syntax should be as clear as possible. Some algorithms cannot be expressed simply, because they are not simple algorithms.
They can however be broken up into simpler pieces, it's called modular programming. Regexes suck because they 1) don't do that and 2) use such terse symbols that one need constantly double escape stuff in order to accomplish the string search.
Hello... we're not using 115 baud teletype machines any longer. The apparent need for robots to decode regex expressions proves that the Perl and regex coders of complex expressions aren't clever, they are nitwits.
jrh wrote:Only a nitwit would write something like that or spend time figuring out what it did.
Ha, ha, ha, ha! Good one.
jrh wrote:Clear, concise, and simple is what I strive for. Complexity for its own sake is horse shit.
Am I the only one who noticed that you emphasized *clear*? I quite agree with you here, and in precisely the order you listed the characteristics. Simplicity in expression is usually gotten to automatically after one strives first for clarity and economy.
heeee cormullion..I completly missed your enhancement on this tool..
need to download that right away... A nice visual addon for my
"Perl 5 Desktop Reference pocket from 1996" ;-) I just recovered
from shelf, hidden behind a Tcl-Pedia-Book the size of a b/w-TV
(a good place to hide btw.. being a pocket containing Perl..)..
Great.. now if they only would remove the regex-part from it,
which is clearly simply with that tool,i would be pleased to pay
'Only 19.95 euro' for it..
Meanwhile im doing, and will be for the next week,
some masogistic regex debugging I not happy about..