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