|
![](/i/fill.gif) |
>> 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
|
![](/i/fill.gif) |