Invisible <voi### [at] devnull> 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

Invisible <voi### [at] devnull> 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'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

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

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

>> 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

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

Invisible <voi### [at] devnull> 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

>> 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.

I think he meant using a parser library, not writing one from scratch. 
Indeed writing a parser (or a regex library) would be a total overkill for 
pretty much any project.

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> >> 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.

> I think he meant using a parser library, not writing one from scratch. 

  I was talking about parser libraries (you know, those which eat BNF or
other such syntax definition languages).

  If you had to code a parser from scratch, it would be a hundred times
more work still.

> Indeed writing a parser (or a regex library) would be a total overkill for 
> pretty much any project.

  *Using* a parser library for something which can be easily expressed with
a regexp string would be complete overkill.

-- 
                                                          - Warp

Post a reply to this message