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

>> Notice that since this is written in a /real/ programming language and
>> not a text string, we can do
>>
>> and save a little typing.
>
> You can do that with many regexp engines too. That's what I meant by
> "trivial macros".

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

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

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

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.

Post a reply to this message