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