Invisible escreveu:
>>> Um, *yes*. Why, do you think it doesn't have worth?
>>
>> it's far more verbose and, thus, hurts readability?
> 
> Far more verbose, and as a consequence it's almost self-explanatory what 
> it does. (Unlike a collection of symbols that have no widely-accepted 
> meaning outside of regex languages...)

symbols like $ or >>=?

yeah, every language has them and you *learn* to live with them.  or you 
just endlessly refuse to learn and whine all day long about them...

you are correct though in that the Lisp way of spelling out names is 
more self-explanatory than the Haskell abuse of perlisms.  At least for 
outsiders.  For insiders, you know by personal experience that a concise 
DSL made out of single chars is much more practical... which is why you 
can do it in Lisp with macros too!

>> then try this in your little language:
>>
>> // A phone number with or without hyphens:
>> [2-9]\d{2}-?\d{3}-?\d{4}
>>
>> It looks pretty much like a template for a phone number. I'm sure yours
>> will look like a little backwards forth script and will be much harder
>> to figure out.
> 
> I actually can't figure out what that does, so I can't implement it.

BS.

>> I also wonder if it's the postfix nature of regexes that bothers you...
> 
> No, mostly it comes down to these:
> 1. Commands have cryptic names like "*" or "+".

more than frakkin' $ or >>= ??!

you quite throw away reason completely when you try to invent reasons 
for why you dislike something, don't you?

> 2. Literal characters aren't quoted, so it's hard to tell what's literal 
> and what's a command.

there's only .*+?^$\ for commands and the rest are grouping chars ()[]{} 
and literal chars.  what's to be confused?

> (And 3. since spaces are literal characters, you can't even use spacing 
> to make the structure of the expression clearer.)

you can in perl regex extensions.

-- 
a game sig: http://tinyurl.com/d3rxz9

Post a reply to this message

On 11/11/2010 03:52 PM, Warp wrote:
> Invisible<voi### [at] devnull>  wrote:
>> Actually, I found a rather interesting description of the history of
>> Unix the other day. I'll have to see if I can find it again. As you read
>> it, you discover that many design decisions that look stupid are in fact
>> merely obsolete. They served a purpose 60 years ago, it's just that they
>> aren't the best choice any more.
>
>    That would be quite strange, given that Unix was originally developed
> 41 years ago.

How do you know all these things?

>> These days, the fashion seems to be for everything from print servers to
>> network hubs to be controlled by HTML over HTTP. Which is equally
>> stupid, but looks more pretty...
>
>    Well, it has the advantage that it's still relatively low-bandwidth and
> usable with any web browser in any system, and you can do things with the
> mouse.
>
>    Of course the downside is that you need something that can run a web
> browser.

You need something that supports HTTP, HTML, JavaScript, the DOM, and 
[typically] supports these things with all the same glitches and bugs as 
Internet Explorer 4.5 >_<

What's that? You wanted to reconfigure all your print servers from a 
script? Good luck with that...

Post a reply to this message

Invisible escreveu:
> On 11/11/2010 03:52 PM, Warp wrote:
>> Invisible<voi### [at] devnull>  wrote:
>>> Actually, I found a rather interesting description of the history of
>>> Unix the other day. I'll have to see if I can find it again. As you read
>>> it, you discover that many design decisions that look stupid are in fact
>>> merely obsolete. They served a purpose 60 years ago, it's just that they
>>> aren't the best choice any more.
>>
>>    That would be quite strange, given that Unix was originally developed
>> 41 years ago.
> 
> How do you know all these things?

he is omniscient.  You are just a puny ignorant human.

-- 
a game sig: http://tinyurl.com/d3rxz9

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> 1. Commands have cryptic names like "*" or "+".

  You might as well argue that math is cryptic because it uses notation
like "1+2=3".

-- 
                                                          - Warp

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> >    That would be quite strange, given that Unix was originally developed
> > 41 years ago.

> How do you know all these things?

  There are two friends of everybody. The name of the first one starts
with a G and the name of the second one starts with a W.

-- 
                                                          - Warp

Post a reply to this message

Invisible wrote:
>>>> (That is, optional sign, one or more digits, optional decimal point
>>>> followed by one or more digits, optional E followed by optional sign
>>>> followed by one to three digits.)
>>>
>>> If I've understood the spec correctly, it's
>>>
>>> do
>>> option (char '+' <|> char '-')
>>> many1 digit
>>> option (char '.')
>>> many1 digit
>>> option (do char 'E'; option (char '+' <|> char '-'); many1 digit)
>>
>> Bzzzt. Sorry. That requires at least a 2-digit number.
> 
> I don't follow. Where do you think by definition deviates from your spec?

Your parser won't parse "+3" as a valid number.

> I've never seen a system that can do that, but I guess that doesn't 
> prove a lot.

Basically, if you wanted the sign, you could do something like

string sign = "(+|-)?";

and then construct your regexp out of parts. Basically, just like you did. 
It's not because "your parser is in a real language". It's because you're 
using whatever language the parser is in to construct the match expression 
and I didn't.

>>> You can also factor the task into smaller pieces:
>>
>> Yeah, that's just a text substitution in the regexp expression.
> 
> Sure. Except without any guarantee of syntactic correctness.

Again, until the first time you run it. So?

Clearly you have no guarantee of semantic correctness, so this really isn't 
a problem, given that with your syntactic correctness you still got the 
expression wrong. :-)

>>> With a regex, on the other hand, you cannot even statically guarantee
>>> that a given string is even a syntactically valid regex.
>>
>> Nonsense. How'd you get that?
> 
> Not every string is a valid regex. You have to follow the syntax rules. 
> But this is not checked at compile-time (and usually /cannot/ be checked 
> at compile-time). So if you make a typo in your regex, you won't find 
> out until runtime.

It can be checked at compile time if your language cares to. That's not an 
aspect of the regexp, but an aspect of you using Haskell.

And if you wrote the code and never ran it, then guess what, you have worse 
problems than syntax errors in your regexps.

> If you start constructing regexs programmatically, your problems just 
> multiplied.
> 
> On the other hand, with a /real/ parser library, both of these grave 
> problems immediately vanish into thin air.

How do you construct your parser programatically in Haskell? That looks like 
code to me.

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message

Warp wrote:
> nemesis <nam### [at] gmailcom> wrote:
>> do you really believe spelling out "option (char '+' <|> char '-')" is 
>> any worth as opposed to "(\+|-)"?
> 
>   Btw, "(\+|-)" is unnecessarily complex. Just use "[+-]". That's exactly
> what the [] syntax is for.

Good point. That was my bad.

-- 
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 wrote:
> If there are more than three digits, the above parser fails, and no 
> other alternatives are tried (i.e., no backtracking).

Then you aren't doing what regular expressions can do.

In order to *get* the power of regexp, *your* parser has to backtrack. So if 
you turn backtracking off, there are trivial regular expressions you can't 
match. If you turn backtracking on, you're using more time and space than a 
regular expression engine.

-- 
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 wrote:
> The reason I put up with TeX, in spite of its innumerable and obvious 
> limitations, is that it produces very, very nice output. troff doesn't 
> seem to compare to that.

I'm guessing you've never run troff, but only nroff. I'm also guessing that 
if you *have* run troff, you've only run it using the man page macros.


-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message

>> If there are more than three digits, the above parser fails, and no
>> other alternatives are tried (i.e., no backtracking).
>
> Then you aren't doing what regular expressions can do.

I don't see how that is the case.

> In order to *get* the power of regexp, *your* parser has to backtrack.
> So if you turn backtracking off, there are trivial regular expressions
> you can't match. If you turn backtracking on, you're using more time and
> space than a regular expression engine.

Do you have a concrete example?

Post a reply to this message

On 11/11/2010 08:28 PM, Darren New wrote:
> Invisible wrote:
>> The reason I put up with TeX, in spite of its innumerable and obvious
>> limitations, is that it produces very, very nice output. troff doesn't
>> seem to compare to that.
>
> I'm guessing you've never run troff, but only nroff. I'm also guessing
> that if you *have* run troff, you've only run it using the man page macros.

Your guess is as good as mine! ;-)

Post a reply to this message

>>> it's far more verbose and, thus, hurts readability?
>>
>> Far more verbose, and as a consequence it's almost self-explanatory
>> what it does. (Unlike a collection of symbols that have no
>> widely-accepted meaning outside of regex languages...)
>
> symbols like $ or >>=?

FWIW, I think that >>= is a stupid name choice too. Especially for a 
function that you almost never need to mention by name anyway...

> yeah, every language has them and you *learn* to live with them. or you
> just endlessly refuse to learn and whine all day long about them...

Look who's whining.

> you are correct though in that the Lisp way of spelling out names is
> more self-explanatory than the Haskell abuse of perlisms.

Almost all of Haskell's operators are just standard mathematical symbols 
that everybody already knows. I consider this /more/ readable, not less.

Perl, on the other hand, seems to choose characters at random on a 
"which punctuation marks haven't we used yet?" basis. :-P

(There are of course Haskell packages that define rather too many 
obscure operators. For example, the arrows package defines operators 
such as ***, &&& and >==>. I end up having to look them up every single 
time I need to know what they do. I don't consider this to be a good idea.)

>>> then try this in your little language:
>>>
>>> // A phone number with or without hyphens:
>>> [2-9]\d{2}-?\d{3}-?\d{4}
>>>
>>> It looks pretty much like a template for a phone number. I'm sure yours
>>> will look like a little backwards forth script and will be much harder
>>> to figure out.
>>
>> I actually can't figure out what that does, so I can't implement it.
>
> BS.

...or you could have just told me what it does rather than swearing 
about it...

>> 1. Commands have cryptic names like "*" or "+".
>
> more than frakkin' $ or >>= ??!
>
> you quite throw away reason completely when you try to invent reasons
> for why you dislike something, don't you?

You've managed to find two operators in the entire Haskell language 
which are a bit dubious. Big deal.

>> 2. Literal characters aren't quoted, so it's hard to tell what's
>> literal and what's a command.
>
> there's only .*+?^$\ for commands and the rest are grouping chars ()[]{}
> and literal chars. what's to be confused?

How about "-"? That's not on your list. I'm pretty sure I saw some 
examples mentioning ":" as well. How many others are there?

(Of course, it's a trick question. The answer depends on "which of the 
20,000 regex variants are we arguing about?")

>> (And 3. since spaces are literal characters, you can't even use
>> spacing to make the structure of the expression clearer.)
>
> you can in perl regex extensions.

So how do you tell the difference between literal whitespace and 
whitespace that's just for readability?

Post a reply to this message

On 11/11/2010 05:07 PM, Warp wrote:
> Invisible<voi### [at] devnull>  wrote:
>> 1. Commands have cryptic names like "*" or "+".
>
>    You might as well argue that math is cryptic because it uses notation
> like "1+2=3".

I'm sure you can find an ample supply of people who make precisely this 
argument.

Almost none of them are arguing that 1+2=3 is cryptic though. They're 
arguing about some equation with sums, limits, Greek and Hebrew letters, 
wonky arrows, funny hats on things, and abbreviations like "tan", "Gal" 
and "Arg".

The basics of mathematical notation are so ubiquitous throughout the 
Western world that nobody considers it cryptic. And it's no coincidence 
that most programming languages copy this notation - after all, 
everybody already knows what it does.

Anyone who's used a computer for a length of time is probably familiar 
with "*" as a wildcard character, so that's not too bad. It's the other 
characters which are less self-evident. (Plus the fact that "*" is 
actually a prefix operator, which I hadn't realised.)

Post a reply to this message

On 11/11/2010 08:20 PM, Darren New wrote:
> Invisible wrote:
>>>>> (That is, optional sign, one or more digits, optional decimal point
>>>>> followed by one or more digits, optional E followed by optional sign
>>>>> followed by one to three digits.)
>>>>
>>>> If I've understood the spec correctly, it's
>>>>
>>>> do
>>>> option (char '+' <|> char '-')
>>>> many1 digit
>>>> option (char '.')
>>>> many1 digit
>>>> option (do char 'E'; option (char '+' <|> char '-'); many1 digit)
>>>
>>> Bzzzt. Sorry. That requires at least a 2-digit number.
>>
>> I don't follow. Where do you think by definition deviates from your spec?
>
> Your parser won't parse "+3" as a valid number.

Huh? Oh wait, I didn't see the "optional" word before the decimal point.

So assuming I'm guessing the bracketing correctly, you want

   do
     option (char '+' <|> char '-')
     many1 digit
     option (do char '.'; many1 digit)
     option (do char 'E'; option (char '+' <|> char '-'); many1 digit)

>> Sure. Except without any guarantee of syntactic correctness.
>
> Again, until the first time you run it. So?

If you don't see why this is critically important, I'm not sure what 
else I can say to that...

> Clearly you have no guarantee of semantic correctness, so this really
> isn't a problem, given that with your syntactic correctness you still
> got the expression wrong. :-)

Semantic correctness is impossible to guarantee.

>> Not every string is a valid regex. You have to follow the syntax
>> rules. But this is not checked at compile-time (and usually /cannot/
>> be checked at compile-time). So if you make a typo in your regex, you
>> won't find out until runtime.
>
> It can be checked at compile time if your language cares to. That's not
> an aspect of the regexp, but an aspect of you using Haskell.

I've yet to find a Haskell regex library that provides compile-time 
guarantees either. After all, it's just a flat string with no structure.

> And if you wrote the code and never ran it, then guess what, you have
> worse problems than syntax errors in your regexps.

That's like saying "type checking is pointless, because you have to test 
your code anyway". Yes, you /do/ have to test your code. But if the 
computer can find the easy bugs instantly without you having to wait for 
the entire test suite to run, you get stuff done a lot quicker.

>> If you start constructing regexs programmatically, your problems just
>> multiplied.
>>
>> On the other hand, with a /real/ parser library, both of these grave
>> problems immediately vanish into thin air.
>
> How do you construct your parser programatically in Haskell? That looks
> like code to me.

A parser is just a data structure. For example, "digit" is a parser, and 
when you say "many1 digit", you're calling the "many1" function, passing 
it the "digit" parser as argument, and getting a new parser as the 
result. You just programmatically constructed a parser.

Obviously that's a fairly trivial example, but you're manipulating 
parser objects with a Turing-complete programming language. You get the 
idea.

Of course, you can manipulate strings-that-happen-to-be-regexs in a 
similar way. It's just that there's no checking of any kind that what 
you're doing with them is sensible. It's a bit like trying to build an 
XML file by string manipulation. Yes, it can be done. Yes, you can make 
it work. And yes, it's incredibly fragile. This is why almost everybody 
uses a real XML library that guarantees that the resulting XML document 
will be at least well-formed, if nothing else.

Post a reply to this message

Le 12/11/2010 10:52, Invisible a écrit :
> Anyone who's used a computer for a length of time is probably familiar
> with "*" as a wildcard character,

Unless it's a SQL usage, where the wildcard for any string is "%"
instead of "*" (when not using regular expression).
And of course "_" is the substitute for one character in SQL (instead of
"?" in some shell... and of "." in other places)

Post a reply to this message

Invisible wrote:
>>> Sure. Except without any guarantee of syntactic correctness.
>>
>> Again, until the first time you run it. So?
> 
> If you don't see why this is critically important, I'm not sure what 
> else I can say to that...

Oh, it would be handy, sure. But it's trivial to test whether a literal 
regexp is syntactically valid.  It's no more "critically important" to 
ensure a literal regular expression is valid before you run it than it is to 
ensure a Haskell program is valid before you compile it.

>> Clearly you have no guarantee of semantic correctness, so this really
>> isn't a problem, given that with your syntactic correctness you still
>> got the expression wrong. :-)
> 
> Semantic correctness is impossible to guarantee.

Yes, and that's my point.  Even with your syntactic correctness, you got the 
parser for the numbers wrong.

> I've yet to find a Haskell regex library that provides compile-time 
> guarantees either. After all, it's just a flat string with no structure.

So is a printf statement, yet GCC manages to check that when it's a literal.

Actually, I wouldn't be surprised if Perl or other languages with actual 
regexp literals in the syntax of the language checked them for correctness 
at compile time.

>> And if you wrote the code and never ran it, then guess what, you have
>> worse problems than syntax errors in your regexps.
> 
> That's like saying "type checking is pointless, because you have to test 
> your code anyway". Yes, you /do/ have to test your code. But if the 
> computer can find the easy bugs instantly without you having to wait for 
> the entire test suite to run, you get stuff done a lot quicker.

Certainly. But it's pretty easy to check in an external program, since there 
*isn't* type information etc built into the regular expression. Chances are 
if it's big enough to need testing, you're going to develop it in a separate 
program full of test strings and then copy it into the production system.

> A parser is just a data structure. For example, "digit" is a parser, and 
> when you say "many1 digit", you're calling the "many1" function, passing 
> it the "digit" parser as argument, and getting a new parser as the 
> result. You just programmatically constructed a parser.

How do you build a parser based on (for example) what the user typed in at 
runtime, while still ensuring syntactic correctness?

> Obviously that's a fairly trivial example, but you're manipulating 
> parser objects with a Turing-complete programming language. You get the 
> idea.

Show me an example of such manipulation?

> Of course, you can manipulate strings-that-happen-to-be-regexs in a 
> similar way. It's just that there's no checking of any kind that what 
> you're doing with them is sensible. It's a bit like trying to build an 
> XML file by string manipulation. Yes, it can be done. Yes, you can make 
> it work. And yes, it's incredibly fragile.

No it's not.

> This is why almost everybody 
> uses a real XML library that guarantees that the resulting XML document 
> will be at least well-formed, if nothing else.

Uh, yes. And that's the way you make it not fragile. I'm not following you.

If you're using a library to construct regular expressions, of course the 
library is going to be invoked in a way that makes it impossible to 
construct syntactically invalid regular expressions, just like your parser is.

You're comparing Haskell against brain-dead worst-possible-stupidity regular 
expression libraries, and saying "See? My way is better!"

-- 
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 wrote:
> How about "-"? That's not on your list. I'm pretty sure I saw some 
> examples mentioning ":" as well. How many others are there?

Those are both shortcuts for typing that aren't part of the formalism. You 
can take any regexp with that and expand it into one without in a trivial 
way.   Basically, 0-9 means 0123456789.

> So how do you tell the difference between literal whitespace and 
> whitespace that's just for readability?

You use a different symbol for the regular whitespace, like "\ " or like 
:space: or something like that.

-- 
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 wrote:
> The basics of mathematical notation are so ubiquitous throughout the 
> Western world 

And the basics of regexp notation is mathematical. As well as being 
ubiquitous throughout the programming world. Which is why we're equating the 
two.

> Anyone who's used a computer for a length of time is probably familiar 
> with "*" as a wildcard character, so that's not too bad. 

And where do you think the "*" meaning "wildcard" came from?

> It's the other characters which are less self-evident. 

I'm sure you'd find quite a few mathematicians being confused by
    6 = 2 * 3
    2 = 6 / 3
which is why APL used an actual multiplication and division sign.

>(Plus the fact that "*" is 
> actually a prefix operator, which I hadn't realised.)

No it isn't.

-- 
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 wrote:
>>> If there are more than three digits, the above parser fails, and no
>>> other alternatives are tried (i.e., no backtracking).
>>
>> Then you aren't doing what regular expressions can do.
> 
> I don't see how that is the case.

You really should learn the essential basics of an entire heirarchy of 
formal language theory.


>> In order to *get* the power of regexp, *your* parser has to backtrack.
>> So if you turn backtracking off, there are trivial regular expressions
>> you can't match. If you turn backtracking on, you're using more time and
>> space than a regular expression engine.
> 
> Do you have a concrete example?

http://swtch.com/~rsc/regexp/regexp1.html

Or, in your language
    many (char 'a')
    many (char 'a')
    many (char 'a')
    char 'a'
    char 'a'
    char 'a'
Now match that against "aaaaaa".

The problem is the first "many (char 'a')" eats the whole string.

Without backtracking, you claim the string fails to match.
*With* backtracking, you're now taking an exponential amount of time to 
match something you could match in six comparisons.

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message

>> Semantic correctness is impossible to guarantee.
>
> Yes, and that's my point. Even with your syntactic correctness, you got
> the parser for the numbers wrong.

So because you can't find /all/ bugs automatically, it's pointless to 
try to find /any/ bugs automatically?

All I can say to that is: I do not agree.

>> It's a bit like trying to build an
>> XML file by string manipulation. Yes, it can be done. Yes, you can
>> make it work. And yes, it's incredibly fragile.
>
> No it's not.

I give up.

> If you're using a library to construct regular expressions, of course
> the library is going to be invoked in a way that makes it impossible to
> construct syntactically invalid regular expressions, just like your
> parser is.
>
> You're comparing Haskell against brain-dead worst-possible-stupidity
> regular expression libraries, and saying "See? My way is better!"

I have yet to see anybody construct a regex in any way other than typing 
it out by hand, or gluing strings together by hand.

Post a reply to this message

Darren New wrote:
> http://swtch.com/~rsc/regexp/regexp1.html

Oh, and given that .NET compiles regular expression matches down to machine 
code, I was really rather surprised to discover that it too exhibits 
exponential runtime for the shown test expressions, even tho it doesn't need 
to. I can't imagine why you'd go to the effort of having an option to 
compile the thing to machine code if you're going to be too lazy to do the 
trivial check it takes to determine whether you need a linear or exponential 
algorithm.

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message

>> The basics of mathematical notation are so ubiquitous throughout the
>> Western world
>
> And the basics of regexp notation is mathematical. As well as being
> ubiquitous throughout the programming world. Which is why we're equating
> the two.

Apparently you have a radically different idea of "ubiquitous" than I do...

Post a reply to this message

>> Do you have a concrete example?
>
> http://swtch.com/~rsc/regexp/regexp1.html
>
> Or, in your language
> many (char 'a')
> many (char 'a')
> many (char 'a')
> char 'a'
> char 'a'
> char 'a'
> Now match that against "aaaaaa".
>
> The problem is the first "many (char 'a')" eats the whole string.
>
> Without backtracking, you claim the string fails to match.
> *With* backtracking, you're now taking an exponential amount of time to
> match something you could match in six comparisons.

I don't understand the specification.

Post a reply to this message

Invisible wrote:
>>> Semantic correctness is impossible to guarantee.
>>
>> Yes, and that's my point. Even with your syntactic correctness, you got
>> the parser for the numbers wrong.
> 
> So because you can't find /all/ bugs automatically, it's pointless to 
> try to find /any/ bugs automatically?

No. Because you can't find semantic bugs, it's pointless to moan about a 
simple reliable bug that gets reproduced the first time you run the code, if 
not sooner.  It's almost as silly to complain about a regexp library not 
ensuring syntactic correctness before you invoke the library as it is to 
complain about a compiler that doesn't issue error messages until you try to 
compile something.

For a regexp literal, it's trivial to check it's syntactically valid, 
*because* it doesn't depend on the rest of the program.

>>> It's a bit like trying to build an
>>> XML file by string manipulation. Yes, it can be done. Yes, you can
>>> make it work. And yes, it's incredibly fragile.
>>
>> No it's not.
> 
> I give up.

<Yoda> And that is why you fail. </Yoda>

You're making assertions with no experience. You've already admitted you 
don't know how regular expressions work, yet here you are telling *me* that 
building them programatically is "incredibly fragile".  You're talking out 
your ass, my dear.

> I have yet to see anybody construct a regex in any way other than typing 
> it out by hand, or gluing strings together by hand.

You don't even know how they work, so I am not at all surprised you haven't 
seen the more sophisticated mechanisms. Just off the top of my head, 
GUI-wise that you may have seen, there's Agent Ransack's expression builder.

http://www.cs.uiuc.edu/class/fa05/cs475/Lectures/new/lec05.pdf

http://www.physicsforums.com/showthread.php?t=265064

There are also any number of systems that'll build lexers for you.

(I'd like you to note that some of these are college lecture course notes. 
This is basic fundamental stuff that everyone with a degree in CS should 
know. So it's not like we're pushing some bizarre esoteric edge-case at you.)

In any case, a regexp is generally not powerful enough that you need to 
build it programatically. Indeed, that's precisely the point.

-- 
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 wrote:
> Apparently you have a radically different idea of "ubiquitous" than I do...

Regular expressions are the same as state machines.

Let me list a few of the programs I use every day that support and use 
regular expressions:

.NET
VI
EMacs
Grep
Find
Bash
Perl
Awk
Sed
Flex
javascript
Tcl
Haskell
Pretty much every editor above the level of notepad
Pretty much every programming language since COBOL

Let me list a few of the programs that support the parser you prefer:

Haskell

So, yeah, the fact that your education sucks doesn't mean bupkiss about what 
actually goes on in the real world. :-)

-- 
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 wrote:
>>> Do you have a concrete example?
>>
>> http://swtch.com/~rsc/regexp/regexp1.html
>>
>> Or, in your language
>> many (char 'a')
>> many (char 'a')
>> many (char 'a')
>> char 'a'
>> char 'a'
>> char 'a'
>> Now match that against "aaaaaa".
>>
>> The problem is the first "many (char 'a')" eats the whole string.
>>
>> Without backtracking, you claim the string fails to match.
>> *With* backtracking, you're now taking an exponential amount of time to
>> match something you could match in six comparisons.
> 
> I don't understand the specification.

I even expressed it in Haskell-ish syntax.

"Zero or more A's, followed by zero or more A's, followed by zero or more 
A's, followed by three A's."

The fact that you can't read the link I provided is screaming out that you 
need to learn how to read that link. Not knowing even the basics of regular 
expressions is like not knowing even the basics of TCP.

-- 
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 wrote:
> I have yet to see anybody construct a regex in any way other than typing 
> it out by hand, or gluing strings together by hand.

And you didn't actually google for something like "programatically construct 
regular expressions", right?

http://www.phpclasses.org/package/5776-PHP-Build-regular-expressions-programmatically.html#description

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message

"Haskell was developed by Isaac Newton in the 15th Century as a tool to 
help his investigations into the Alchemic arts. It was rediscovered in 
the 1980s by three Cambridge undergraduates who were browsing through 
Newton's laboratory notebooks looking for smutty jokes in the margins, 
and has since developed into an elaborate joke perpetrated by elite 
computer scientists who believe that predictable order of execution is 
contrary to natural law. The current version of Haskell is Haskell 1714, 
which adds syntactic sugar for Zygohistomorphic Premorphisms to the 
original language definition of 1693."

Post a reply to this message

Other amusing quotes of the week:

"Also [scripting languages] 'don't scale well', which I guess means that 
they don't make it inconvenient to design badly."

"someday we'll need meta-software that converts from obsolete languages 
into modern ones"
"Don't we call that compilers?"
[Actually that's kinda backwards, isn't it?]

"how about a language where you program with unit vectors: orientation 
oriented programming"

"what you just typed isn't even well typed"
(The compiler tells me this all the time BTW...)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> "Haskell was developed by Isaac Newton in the 15th Century as a tool to
> help his investigations into the Alchemic arts. It was rediscovered in
> the 1980s by three Cambridge undergraduates who were browsing through
> Newton's laboratory notebooks looking for smutty jokes in the margins,
> and has since developed into an elaborate joke perpetrated by elite
> computer scientists who believe that predictable order of execution is
> contrary to natural law. The current version of Haskell is Haskell 1714,
> which adds syntactic sugar for Zygohistomorphic Premorphisms to the
> original language definition of 1693."

its from the mailing list, isn't it?

Post a reply to this message

On 12/11/2010 08:44 PM, nemesis wrote:

> its from the mailing list, isn't it?

What, you think *I* could invent something this awesome?

Yes, of course it's from the mailing list...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

>> I don't understand the specification.
>
> I even expressed it in Haskell-ish syntax.
>
> "Zero or more A's, followed by zero or more A's, followed by zero or
> more A's, followed by three A's."

In what way is that different from "zero or more As"?

> The fact that you can't read the link I provided is screaming out that
> you need to learn how to read that link. Not knowing even the basics of
> regular expressions is like not knowing even the basics of TCP.

Except that regular expressions are an obscure topic used almost nowhere 
except in text-mangling languages like Perl.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On 12/11/2010 05:24 PM, Darren New wrote:
> Invisible wrote:
>> Apparently you have a radically different idea of "ubiquitous" than I
>> do...
>
> Regular expressions are the same as state machines.

Sure. Just expressed in an unecessarily cryptic mannar.

If a state machine is a good way to solve your problem, why not express 
it clearly? And why limit it to only operating on characters?

> Let me list a few of the programs I use every day that support and use
> regular expressions:
>
> .NET
> VI
> EMacs
> Grep
> Find
> Bash
> Perl
> Awk
> Sed
> Flex

...so, basically Unix text-mangling tools then?

> javascript

That's the third time I've heard somebody say that. I've yet to see it.

> Pretty much every editor above the level of notepad

It's no secret that emacs and vi think this is a good idea. I don't 
recall seeing any other editors use it though.

> Pretty much every programming language since COBOL

Really. Because your list seems to include only low-level scripting 
languages. I don't see regexs in Pascal, C, Eiffel, etc.

> Let me list a few of the programs that support the parser you prefer:
>
> Haskell

I'm pretty sure that Haskell is not the only programming language that 
offers real parser construction tools. Parsec is merely an example of 
such. (If you /really/ want to split hairs, Parsec has actually been 
ported to [at least] Java, Ruby and C#. But that's not the point.)

> So, yeah, the fact that your education sucks doesn't mean bupkiss about
> what actually goes on in the real world. :-)

Right. Because Unix text-mangling is all that happens in "the real 
world", naturally...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

>> I give up.
>
> <Yoda> And that is why you fail. </Yoda>
>
> You're making assertions with no experience. You've already admitted you
> don't know how regular expressions work, yet here you are telling *me*
> that building them programatically is "incredibly fragile". You're
> talking out your ass, my dear.

Goodbye.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 wrote:
>>> I give up.
>>
>> <Yoda> And that is why you fail. </Yoda>
>>
>> You're making assertions with no experience. You've already admitted you
>> don't know how regular expressions work, yet here you are telling *me*
>> that building them programatically is "incredibly fragile". You're
>> talking out your ass, my dear.
> 
> Goodbye.

Sorry. That *was* kind of harsh.

-- 
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:
> If a state machine is a good way to solve your problem, why not express 
> it clearly? And why limit it to only operating on characters?

It is clearly expressed, and it's not limited to only operating on 
characters.  What can I say?

> ...so, basically Unix text-mangling tools then?

No. Most anything working with text.

>> Pretty much every programming language since COBOL
> 
> Really. Because your list seems to include only low-level scripting 
> languages. I don't see regexs in Pascal, C, Eiffel, etc.

Libraries, dear. Few languages have them built into the syntax.

>> Let me list a few of the programs that support the parser you prefer:
>>
>> Haskell
> 
> I'm pretty sure that Haskell is not the only programming language that 
> offers real parser construction tools. Parsec is merely an example of 
> such. 

Sure. And the other languages have real parser tools too.  Bison, for 
example, if nothing else.

>> So, yeah, the fact that your education sucks doesn't mean bupkiss about
>> what actually goes on in the real world. :-)
> 
> Right. Because Unix text-mangling is all that happens in "the real 
> world", naturally...

No, because it's used much more widely, yet you've never seen it.  Every 
state machine is a regular expression matcher. Those pictures of state 
transitions in TCP? Regular expressions.  The "railroad track" diagrams in 
the Pascal standard? Regular expressions.

-- 
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:
>>> I don't understand the specification.
>>
>> I even expressed it in Haskell-ish syntax.
>>
>> "Zero or more A's, followed by zero or more A's, followed by zero or
>> more A's, followed by three A's."
> 
> In what way is that different from "zero or more As"?

That's not the point. Replace "A" with "phone number" and you have the same 
problem.

> Except that regular expressions are an obscure topic used almost nowhere 
> except in text-mangling languages like Perl.

No, they're really not. That's what I'm trying to explain. That's like 
saying "state machines are really irrelevant" or "parsers are an obscure topic."

-- 
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:
> "Also [scripting languages] 'don't scale well', which I guess means that 
> they don't make it inconvenient to design badly."

Amusingly, that's exactly true. :-)

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Darren New wrote:
> > http://swtch.com/~rsc/regexp/regexp1.html

> Oh, and given that .NET compiles regular expression matches down to machine 
> code, I was really rather surprised to discover that it too exhibits 
> exponential runtime for the shown test expressions, even tho it doesn't need 
> to. I can't imagine why you'd go to the effort of having an option to 
> compile the thing to machine code if you're going to be too lazy to do the 
> trivial check it takes to determine whether you need a linear or exponential 
> algorithm.

  Well, consider who developed .NET.

  These are the same people who will not bother fixing their broken
C preprocessor even though they know it's broken (they have officially
stated that they won't fix it anytime soon).

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> http://swtch.com/~rsc/regexp/regexp1.html

> Or, in your language
>     many (char 'a')
>     many (char 'a')
>     many (char 'a')
>     char 'a'
>     char 'a'
>     char 'a'

  I think you are confusing "a?" with "a*" (the webpage in question uses
the former).

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> http://swtch.com/~rsc/regexp/regexp1.html
> 
>> Or, in your language
>>     many (char 'a')
>>     many (char 'a')
>>     many (char 'a')
>>     char 'a'
>>     char 'a'
>>     char 'a'
> 
>   I think you are confusing "a?" with "a*" (the webpage in question uses
> the former).

It works either way. The point is to make the first thing (A* or A?) match 
what needs to be left behind to match the second thing (A). Then you have to 
backtrack to get a match.

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message

Warp wrote:
>   These are the same people who will not bother fixing their broken
> C preprocessor even though they know it's broken (they have officially
> stated that they won't fix it anytime soon).

BTW, I don't think it's likely a matter of "won't bother" as much as it is 
"have decided backwards-bug-compatibility is more important to our business 
than being correct."  There are a fair number of bugs in various MS products 
that don't get fixed because people are depending upon the buggy behavior.

Remind me again what the problem is?

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message

On 11/14/2010 12:20 PM, Darren New wrote:
> Warp wrote:
>> These are the same people who will not bother fixing their broken
>> C preprocessor even though they know it's broken (they have officially
>> stated that they won't fix it anytime soon).
>
> BTW, I don't think it's likely a matter of "won't bother" as much as it
> is "have decided backwards-bug-compatibility is more important to our
> business than being correct." There are a fair number of bugs in various
> MS products that don't get fixed because people are depending upon the
> buggy behavior.
>
> Remind me again what the problem is?
>
Ugh.. Don't you just love that. Like Second Life. Their 3D conversion 
code is *wrong* and has been since day one (one reason using it is a 
pain in the ass), but it would "break" millions of scripts to fix it, 
and would be, their words, "confusing", to include an alternate version 
that did work... Gah!

-- 
void main () {
   If Schrödingers_cat is alive or version > 98 {
     if version = "Vista" {
       call slow_by_half();
       call DRM_everything();
     }
     call functional_code();
   }
   else
     call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models, 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message

Patrick Elliott wrote:
> Ugh.. Don't you just love that. 

It is indeed one of the primary banes of computer programming. And as 
programs get more and more sophisticated and less and less reasonable to 
write with just one group of people, it's only going to get worse.


-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message

>> Pretty much every editor above the level of notepad
> 
> It's no secret that emacs and vi think this is a good idea. I don't 
> recall seeing any other editors use it though.

http://en.wikipedia.org/wiki/Comparison_of_text_editors#Basic_features

Post a reply to this message

On 15/11/2010 11:29 AM, scott wrote:
>>> Pretty much every editor above the level of notepad
>>
>> It's no secret that emacs and vi think this is a good idea. I don't
>> recall seeing any other editors use it though.
>
> http://en.wikipedia.org/wiki/Comparison_of_text_editors#Basic_features

Man. Who knew that so many editors exist?

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> >   These are the same people who will not bother fixing their broken
> > C preprocessor even though they know it's broken (they have officially
> > stated that they won't fix it anytime soon).

> BTW, I don't think it's likely a matter of "won't bother" as much as it is 
> "have decided backwards-bug-compatibility is more important to our business 
> than being correct."  There are a fair number of bugs in various MS products 
> that don't get fixed because people are depending upon the buggy behavior.

> Remind me again what the problem is?

  Basically, preprocessor macro expansion should never create new tokens
unless the token pasting operator (##) is explicitly used to do so. However,
Microsoft's C preprocessor doesn't take this into account at all.

  For example, if you have:

#define STAR *

then /STAR should not start a comment. However, it does start a comment in
MSVC. Likewise if you have:

#define X -1
#define Y -X

then instantiating Y should not be an attempt to decrement a literal.
However, in MSVC it is.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   Basically, preprocessor macro expansion should never create new tokens
> unless the token pasting operator (##) is explicitly used to do so. However,
> Microsoft's C preprocessor doesn't take this into account at all.

I see. I can see where that would (A) really annoy and confuse people 
expecting the standard behavior and (B) would really annoy people who relied 
on it if it got changed. :-) All the more reason to make sure stuff works 
before releasing it.

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> >   Basically, preprocessor macro expansion should never create new tokens
> > unless the token pasting operator (##) is explicitly used to do so. However,
> > Microsoft's C preprocessor doesn't take this into account at all.

> I see. I can see where that would (A) really annoy and confuse people 
> expecting the standard behavior and (B) would really annoy people who relied 
> on it if it got changed. :-) All the more reason to make sure stuff works 
> before releasing it.

  I have really hard time believing that they aren't fixing it because they
don't want to break existing programs. I can't think of a rational situation
where you would *want* the buggy behavior of the preprocessor. It can only
be used for obfuscating code (for example, you don't expect something like
"-x" to really mean "--something_else"; that would be obfuscating beyond
belief).

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Warp wrote:
>>>   Basically, preprocessor macro expansion should never create new tokens
>>> unless the token pasting operator (##) is explicitly used to do so. However,
>>> Microsoft's C preprocessor doesn't take this into account at all.
> 
>> I see. I can see where that would (A) really annoy and confuse people 
>> expecting the standard behavior and (B) would really annoy people who relied 
>> on it if it got changed. :-) All the more reason to make sure stuff works 
>> before releasing it.
> 
>   I have really hard time believing that they aren't fixing it because they
> don't want to break existing programs. 

Well, there's always the possibility that they just don't find it 
economically worthwhile. But yeah, you'd be surprised at what existing 
programs rely on, bugwise. :-) I *don't* think it's because they can't 
figure out how to fix it. I think it's an intentional business decision, for 
whatever reason, not a "our compiler writer guys can't figure out how to fix 
this."

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message