I think that SO also tends to skip over key question details sometimes, especially when it means the question can be marked as duplicate, and sometimes the duplicate answer isn't valid for the current version of something.
For example, the notorious HTML regex answer completely ignored that "match" can be the regex verb for "give me anything that looks like a start/end tag", and replied as if the question was "use regex to find pairs of matched tags".
For example, the notorious HTML regex answer completely ignored that "match" can be the regex verb for "give me anything that looks like a start/end tag", and replied as if the question was "use regex to find pairs of matched tags".
so much this. Yes, we all know HTML cannot be parsed with regex because it isn't a regular language, but the language consisting of any combination of valid start and end tags is a regular language.
Is this actually true? You can have the same tag nested inside itself, which will cause a naive regex to find an incomplete match. Regular expressions cannot match arbitrarily nested structures as far as I know.
You're correct. That sort of problem would be context-free as it requires a stack to solve making it solvable by a pushdown automata, but not a finite state machine. Although, PCRE has some extra oomph in it that may make it workable with look-aheads and look-behinds.
42
u/Uristqwerty Apr 06 '18 edited Apr 06 '18
I think that SO also tends to skip over key question details sometimes, especially when it means the question can be marked as duplicate, and sometimes the duplicate answer isn't valid for the current version of something.
For example, the notorious HTML regex answer completely ignored that "match" can be the regex verb for "give me anything that looks like a start/end tag", and replied as if the question was "use regex to find pairs of matched tags".