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