Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Solving the regex of madness, and snarky answers on StackOverflow (2019)

cargocultcode.com

Post reply on HN
Print view View original

101–110 of 136 posts

Re: Solving the regex of madness, and snarky answers on StackOverflow (2019)

#101

Post by a1369209993 »

chubot wrote: post #84
a1369209993 wrote: post #79

Earlier quoted context omitted.

> This conversation would be a lot clearer with a distinction between "regexes" and "regular languages". Very much so. > In this post, the example given IS a regex, but it IS NOT a regular language: ` # comment` The nongreedy match of .*? isn't a mathematical construct; it implies a backtracking engine. Actually, that's [edit: "it IS NOT a regular language"] wrong, at least in principle. If you're limiting it to only…

Yeah I think you are right -- the nongreedy match can be simply written as a more awkward pattern. I think regular language negation and intersection also help (which the rarer derivatives-based implementations seem to have). They are still regular and equivalent in power, but there's a richer set of operators for writing patterns. I would also divide it into the "recognition problem" and the "parsing/capturing probl…

> common regex APIs that either return the end position (Python's re.match) or search (re.search).

Yeah, I probably should have explicitly said that's what the first translation (`[^a]|a[^b]|ab[^c]|...`) was for; it's a optimization (possibly-backtracking-parser -> [ND]FA) I've used a couple of times to beat things into guaranteed O(N) time.

> But parsing / capturing is more relevant to programmers.

I'd debate "more", since that's a additional thing on top of matching and searching. Any case where you need the former, you also need the latter to even know what to capture. But it's definitely something you do frequently need.

Re: Solving the regex of madness, and snarky answers on StackOverflow (2019)

#102

Post by jancsika »

jameshart wrote: post #62
jancsika wrote: post #34

I love seeing the weirdo CDATA thingy in there! CDATA ftw! E.g., you've got this enormous spec for SVG which includes CSS, but that CSS has syntax inside a style tag which could break XHTML parsers. Amateurs out there are probably thinking, "Well, why not just compromise in the spec and tell implementers to do the same thing that HTML does to parse style tags?" Well, professionals know that cannot work for myriad rea…

The 'weirdo' CDATA thing is the only thing that makes XHTML actually amenable to this approach, because XHTML is tokenizable using a regular expression-based grammar, whereas HTML without CDATA is not. As you're obviosuly aware, the language inside elements is not suitable for XML parsing. Nor is the language inside elements: var y = " ... a naive tokenizer thinks this is in a comment ... var z = "-->" There's a weir…

Part of problem and solution you describe was due to the battle to define who is encapsulating whom, no? The W3C SVG list archive was full of people essentially asking for the ability to flow text and replicate a lot of HTML as part of native SVG. In that dream, it's certainly important to have well-defined behavior for javascript inside SVG since you could have SVG user agents that aren't web browsers. And that means CDATA to hold the non-XML scripting and styling data.

However, at the end of that history HTML was the clear encapsulator and SVG exists either inside it or as a static image in Inkscape, the browser, or some library. So today, scripts inside an SVG are either a curiosity or security nightmare that comes to life when the user clicks "View Image" on an SVG image in their browser.

That leaves only the `` tag content as a potential ambiguity. So I'm curious-- are there examples where content of a `` tag inside an inline SVG causes unpredictable behavior in modern browser HTML parsers? I'm guessing there must be, but I'd like to play with a clear example.

Re: Solving the regex of madness, and snarky answers on StackOverflow (2019)

#103

Post by inopinatus »

jcelerier wrote: post #93
inopinatus wrote: post #58

Earlier quoted context omitted.

Oh, are they here? It’d be fascinating to hear from them. Alternatively, perhap, that hostile tone is suggesting I’m personally unqualified to interpret loosely framed questions? I suppose, since I’ve only been doing it for a few decades, I’m definitely a novice by any standard, and my tendency to observe and follow up on anomalous, incomplete, subtly conflicting, or otherwise inexplicable requirements by investigati…

> Sometimes, we just have to bother reading what's in front of us. You are making an absolutely great example of that. I was absolutely not talking about the original SO post, but about the generally extremely entitled answers which assume the existence of a very specific X to the Y of a post.

If I understand correctly, you're suggesting "Who are you" wasn't directed at me personally, "the person" wasn't referring to the OP but all possible authors, and "the question" wasn't referring to, well, the original SO question at hand, but the class of all possible questions.

If so, then I see, I think: perhaps it was more intended as "Who is anyone to know the purpose and utility (of a question) better than the person who asks that question?"

I can't answer that, since I agree with the sentiment. I'm only really pondering this one specific question, made possible because there's so much extra context with which to interpret the original text. My personal hubris doesn't generalise to the class of all possible questions, and I'd struggle to sympathise with anyone making such an ambit claim.

But then, maybe it wasn't even a question at all.

Re: Solving the regex of madness, and snarky answers on StackOverflow (2019)

#104

Post by crispyambulance »

goto11 wrote: post #42
crispyambulance wrote: post #35

Earlier quoted context omitted.

Long regex's are not the root of all evil but they're certainly a tendril of bad-practice. I would say that the OP's usage, a home-made concoction to find all opening tags in an xhtml doc, crosses the line into bad practice. Get a room and use a parser, people!

So if using regular expressions is "bad practice", how should one write the tokenizer or lexer stage of a parser?

Who said regular expressions are bad practice? Regexes are great but they can get abused easily.

Looking more carefully at the SO question, I am inclined to ask "why?" at least a couple of times because I suspect the answer to the deeper problem the SO OP needs to solve can be worked out with a DOM parser. If not, then definitely a SAX parser could solve that specific problem and it would be more robust than handcrafting a fussy regex.

Re: Solving the regex of madness, and snarky answers on StackOverflow (2019)

#105

Post by AzzieElbab »

goto11 wrote: post #54
AzzieElbab wrote: post #32

Earlier quoted context omitted.

I am guilty of this type of thinking as well. I saw the errors of my ways when I had to fix someone’s else regular expressions

So what do you use instead of regular expressions for such tasks?

That kind of depends on the language I am using, as well as dealing with performance requirements vs readability tradeoffs.

Re: Solving the regex of madness, and snarky answers on StackOverflow (2019)

#106

Post by jameshart »

a1369209993 wrote: post #100
goto11 wrote: post #89

Earlier quoted context omitted.

Does your regex assumes that "-->" must be prefixed by a space? This is not the case in XML. (Also the string "--" must not occur inside a comment, so the last clause is not necessary.)

> Does your regex assumes that "-->" must be prefixed by a space? Yep, because the quoted regex assumed the same thing, and I didn't see a point in editorializing more than necessary. > Also the string "--" must not occur inside a comment, so the last clause is not necessary. "Must not" seems unreliable in webpage parsing. What page does your XHTML parser produce when fed text of the form ` `, for example?

The supplied regex is using extended syntax which ignores whitespace (you can tell because it also includes comments)

Re: Solving the regex of madness, and snarky answers on StackOverflow (2019)

#107

Post by jameshart »

goto11 wrote: post #28
jontro wrote: post #17

Earlier quoted context omitted.

To me it’s a bit ambiguous if the original question is about both html and xhtml. It’s tagged with both

The headline says XHTML. HTML does not even have the self-closing tags the question is concerned about.

The headline said that the author was specifically looking to avoid 'xhtml self-contained tags', but that doesn't mean they could assume the document they were looking in was valid XHTML - just that it might contain XHTML-style 'self-closing' tags.

I've seen plenty of plain HTML files that aren't well-formed XML yet contain
tags.

Re: Solving the regex of madness, and snarky answers on StackOverflow (2019)

#108

Post by jameshart »

Rapzid wrote: post #70
03b17999-4268 wrote: post #4

I haven't read the rest of the thread, but the article is even wronger than the glib replies there. HTML needn't be well formed. There are adhoc rules which let major browsers parse broken HTML. If you do not follow the spec to the letter you will have your tooling break on input that every browser thinks is acceptable. Which is why you always use whatever html parsing library comes with your language. There is no si…

The CDATA section doesn't appear to match this first example from Wikipedia: John Smith ]]> So it's either bugged due to the spaces or there is something else going on I don't understand; complexity. Agree on the sentiment. Through a "Simple made easy" lens, easy or hard, there is a lot of complexity in the task and this solution..

You need to tell your regex engine to ignore whitespace in the expression. The regex handles that fine.

Re: Solving the regex of madness, and snarky answers on StackOverflow (2019)

#109

Post by cyberdelica »

It goes to show, how few people are able to think for themselves.

The question originally asked, is "how to match HTML tags". Not how to parse. Not how to scrape. Simply "match". To which I would say, regex is perfectly suited to the task.

Furthermore - if one simply needs to scrape content, regex is again, perfectly suited. Scraping, is not parsing - and has no real need for a full blown DOM parsing library.

Cargo cult parrots like to say - if the HTML content changes, then one's regex will fail. Well, so will one's DOM parser.

Re: Solving the regex of madness, and snarky answers on StackOverflow (2019)

#110

Post by IshKebab »

inopinatus wrote: post #66
IshKebab wrote: post #64

Earlier quoted context omitted.

Read the regex. It handles self-closing tags fine. Also you're doing the intensely annoying thing that lots of StackOverflow people do of imagining that the asker really wanted to ask a different question. It happens sometimes. But you shouldn't just jump in and assume that they don't know what they want and you're so much smarter than them so you know what they really want. Offer additional answers if you want, but…

You're not the first to take that line, so I'll refer you to my previous observations: https://news.ycombinator.com/item?id=27097403 There's no wild assumption going on here. I just bothered to keep reading, very carefully, everything the original author actually wrote. Then, please, further reflect that Stack Overflow is not Codewars; it is a forum for practical, focused, and relevant problem-solving advice, and at…

> There's no wild assumption going on here. I just bothered to keep reading, very carefully, everything the original author actually wrote.

That doesn't excuse it. You're still inferring stuff that wasn't asked in the actual question.

What happens when someone else comes along who really does want to use a regex? They now have a question without the correct answer and they can't even ask the question themselves because it will be closed as duplicate! Probably by people like you.

Post reply on HN