![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 05/11/2010 04:12 PM, Warp wrote:
> I have always found it curious that you are infatuated with a
> programming language known for the brevity of its programs, yet have
> an almost irrational prejudice against regular expressions.
>
> This is doubly curious because both Haskell and regular expressions
> are based quite heavily on mathematical backgrounds, so it's yet another
> thing in common with them.
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.
OK, so it's convenient to be able to say "foo*bar" and mean "any string
that starts with 'foo' and ends with 'bar'". 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!"
FWIW, I dislike printf format strings for essentially the same reason...
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible escreveu:
> OK, so it's convenient to be able to say "foo*bar" and mean "any string
> that starts with 'foo' and ends with 'bar'". 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!"
>
> FWIW, I dislike printf format strings for essentially the same reason...
you dislike DSLs, point taken.
--
a game sig: http://tinyurl.com/d3rxz9
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible <voi### [at] dev null> wrote:
> 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.
> OK, so it's convenient to be able to say "foo*bar" and mean "any string
> that starts with 'foo' and ends with 'bar'".
Actually it doesn't mean that.
> 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 (vertical bar
signifying in practice a boolean 'or', parentheses for grouping, two
quantification symbols and one "wildcard" symbol). Extended regular
expressions add a few more (the '+' quantification symbol and []), but
the total still remains under 10.
Regular expressions are nowhere near Turing strong. They are state
machines.
I don't know what you are confusing regular expressions with, but they
are not that complicated.
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible <voi### [at] dev null> wrote:
> I've always thought that manpages and the ugliest, lamest, most archaic
> thing ever, so I don't see that that's much of an advantage.
If you have to read a manual through a VT100 terminal, what would you
suggest as a better alternative?
(And yes, even *today* people still need sometimes do things through
ancient terminal emulation. Usually today the connection is encrypted
(ever heard of ssh?) unlike in the early days, but it's still the same
thing.)
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> I've always thought that manpages and the ugliest, lamest, most archaic
>> thing ever, so I don't see that that's much of an advantage.
>
> If you have to read a manual through a VT100 terminal, what would you
> suggest as a better alternative?
Well, yes. But people say "the Amiga is associated with a strong
tradition of graphics work", and that's because it had really ace
software /and hardware/. So when somebody says "typesetting is /the/
killer application for Unix", you don't expect some ugly archaic looking
text-only interface...
> (And yes, even *today* people still need sometimes do things through
> ancient terminal emulation. Usually today the connection is encrypted
> (ever heard of ssh?) unlike in the early days, but it's still the same
> thing.)
Yes, I've used SSH myself. It's quite neat that I can have an old 386
laptop sitting in a cupboard somewhere and operate it basically as if I
was sitting in front of it. On the other hand, would it be so hard to do
so with a less primitive interface? (I suppose I should have installed X...)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible wrote:
>>> "The troff(1) typesetting formatter was, as we noted in Chapter 2,
>>> Unix's original killer application."
>>>
>>> Oh really?
>>
>> Yes. troff is what runs when you say "man bash" for example.
>
> Oh, so *that's* what that does?
>
> So when it says "reformatting manpage", it's running troff?
Well, technically, nroff, which takes the same input as troff and tries to
put it on an ASCII stream. Kind of like the difference between firefox and lynx.
> I've always thought that manpages and the ugliest, lamest, most archaic
> thing ever, so I don't see that that's much of an advantage.
Except it was (one of) the first macro-driven multi-output typesetting tool.
> (On the other hand, today's reading suggests that troff is really
> designed to control phototypesetters - whatever those are - and not
> produce stuff on screen...)
A phototypesetter is how you used to do high-quality typesetting before
laser printers. Think of it as a daisywheel laser printer.
>>> Really? The design of PostScript looks fairly UNeconomical to me.
>>
>> No, the *program* is economical.
>
> So you mean it lets you do what you want done without writing too much
> code?
Yes. Considering that it's designed to be shipped over a serial line,
that's a good thing compared to shipping gigabyte bitmaps.
> Well, it has C-style syntax
No it doesn't. Unless you mean curly braces.
--
Darren New, San Diego CA, USA (PST)
Serving Suggestion:
"Don't serve this any more. It's awful."
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Orchid XP v8 wrote:
>you don't expect some ugly archaic looking
> text-only interface...
That's only because you don't know what typesetter machines looked like in
the 1970s.
--
Darren New, San Diego CA, USA (PST)
Serving Suggestion:
"Don't serve this any more. It's awful."
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/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) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible wrote:
> I'd much prefer to see a much bigger separation between what's a literal
> character and what's a command.
Technically, they're all commands. The letter "s" means "match against the
letter s." :-)
> you could probably use
> it to match against streams of other data, not just characters.
You can. For example, Singularity uses "regular expressions" to match
permissions. "if it started as the FTPD server and then fred logged in and
it launched ls, *or* it started as the sshd server and any administrator
logged in, then you launched a shell *then* you launched ls, allow access to
this directory."
> 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.)
: and {} and ^ $ aren't original regular expression characters. Technically
not + either, so I think that's where the 10 come from. The rest are
short-cuts for what you can already otherwise specify (: + { }), or are
useful for programming but outside the theory (^$).
>
>> 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.
Correct. And not only exponential time, but memory as well. A regular
expression is regular because it requires a fixed amount of memory to match
or reject.
> The other thing I dislike is that people seem to have a tendency to use
> regexs where they should be using a real parser.
Yes, well, that's because people are stupid, not regexps.
> But the result is still incredibly fragile.
Yes, because regular expressions can't parse XML. One of the benefits of
regular expressions is you can tell when they'll fail.
> 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.
Only stupid people. Learn regexps, and learn the theory behind them, so when
the boss asks you to write a parser, you know which one to use.
--
Darren New, San Diego CA, USA (PST)
Serving Suggestion:
"Don't serve this any more. It's awful."
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible <voi### [at] dev null> wrote:
> >> 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.
It would become a burden with simple regular expressions.
> > 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.)
Well, regular expressions do not have all of those special characters,
extended regular expressions do. Also, I conflated [ and ] into one "special
character" because they are counterparts of the same special meaning
(in other words, I was more thinking of "keywords" of sorts rather than
individual characters). Likewise for () and {}. Also , is special only
inside {} and : is special only inside [], so I conflated them into the
same "special character".
> > 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 wasn't really talking about perl. (Perl RE's add things like multi-line
matching, which is a lot more complex.)
> 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.
As Darren said, does the fact that regular expressions are abused for
purposes they are not really intended for make them detestable?
Regular expressions are not a really good way of tokenizing some
formatted input. There are other languages much better designed for
that purpose, such as BNF.
> 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.
Writing a parser, even with the aid of a specialized description language
such as BNF, is very laborious. Simple string matching can be often expressed
with very short regular expressions which you can write in a few seconds.
Writing a parser would be complete overkill.
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |