>> It's not the concept of a regular expression as such. It's the fact that
>> all known implementations work by mixing up code and data in the same
>> encrypted string.
>
>    I don't understand what you mean by that.

I'd much prefer to see a much bigger separation between what's a literal 
character and what's a command. In fact, if they didn't try to encode 
the entire expression as a flat character string, you could probably use 
it to match against streams of other data, not just characters. 
(Although admittedly text is probably the most likely place you'd want 
elaborate pattern matching.)

>> But by the time you've
>> added 25 different special characters with a dense set of possible means
>> such that you have an almost Turing-complete language, my reaction is
>> "for God's sake, stop trying to encode the entire language grammar into
>> a text string and go use a /real/ programming language!"
>
>    Regular expressions define less than 10 special characters.

Depending on /which/ regular expressions you mean, of course. Is that 
POSIX Basic Regular Expressions? POSIX Extended Regular Expressions? 
Perl 5.0 Regular Expressions? Perl Compatible Regular Expressions? 
Something else?

A quick inspection of Wikipedia suggests that POSIX ERE involves at 
least .[]^$()\*{}?+|:, which is 16, not 10. (Still, it's not the 
thousands it seemed like last time I tried to learn this stuff.)

>    Regular expressions are nowhere near Turing strong. They are state
> machines.

I recall reading somewhere that Perl's "regular expressions" aren't 
actually regular, and so require exponential time for matching. Truly 
regular expressions apparently require only linear time.

>    I don't know what you are confusing regular expressions with, but they
> are not that complicated.

Perhaps.

The other thing I dislike is that people seem to have a tendency to use 
regexs where they should be using a real parser. For example, I recently 
saw a Haskell example where they used a fistful of regexs to "parse" SVG 
input.

OK, it was an example program. They did it that way so you can run the 
example without having to download and install a real XML parser 
library. But the result is still incredibly fragile. For example, if you 
comment out a chunk of code using an XML comment, the "parser" will 
completely fail to notice that the code is commented out and will 
inspect it anyway, possibly producing very surprising results.

In short, people tend to use regexs for quick and dirty hacks that kinda 
work, rather than doing the job properly with a full parser. And I'm 
really not fond of hacks.

Post a reply to this message