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