Parsers don't have to be complicated
bkaradzic.github.io
Parsers don't have to be complicated
1–10 of 77 posts
Re: Parsers don't have to be complicated
#2If you draw a line from 'ad-hoc byte-wrangling nonsense' to 'parser combinators', this can't be more than 20% along it.
Looking at the linked URL parser, why doesn't it look like
url = do scheme
authority
path
query
fragment
where
scheme = ...
authority = ...
etc.
Re: Parsers don't have to be complicated
#3> LineReader splits input into lines, handles \n and \r\n, and trims the stray trailing \r that malformed input likes to leave behind
Is there a common source of extra \r in malformed inputs, beyond those existing as part of \r\n? Or is this just a dig at Windows-style line endings? If there's something weird going on I think I'd rather fail loudly.
> Bounding the inner scanner to a single line makes “run past the end of a malformed line” unrepresentable rather than merely unlikely.
I don't really see what makes it "unrepresentable", and this reads more like "if you used the right scanning logic, you can't have used the wrong scanning logic".
Re: Parsers don't have to be complicated
#4Unfortunately, simple URL parsing breaks on so many things. There is a reason on why every URL parsing library is at least a few thousand LOCs.
One common way to test it is just to pass ipv6 url: http://[f021:d981:b487:e57d:193e:550e::]/
Re: Parsers don't have to be complicated
#5> LineReader splits input into lines, handles \n and \r\n, and trims the stray trailing \r that malformed input likes to leave behind Is there a common source of extra \r in malformed inputs, beyond those existing as part of \r\n? Or is this just a dig at Windows-style line endings? If there's something weird going on I think I'd rather fail loudly. > Bounding the inner scanner to a single line makes “run past the en…
Sure, start with \r\n, split on \n, now you have a stray \r at the end of every input.
Re: Parsers don't have to be complicated
#6> LineReader splits input into lines, handles \n and \r\n, and trims the stray trailing \r that malformed input likes to leave behind Is there a common source of extra \r in malformed inputs, beyond those existing as part of \r\n? Or is this just a dig at Windows-style line endings? If there's something weird going on I think I'd rather fail loudly. > Bounding the inner scanner to a single line makes “run past the en…
Sure, start with \r\n, split on \n, now you have a stray \r at the end of every input.
But the preceding clause says it handles \r\n. If you're already handling \r\n, what remaining sources of \r are there, that you'd actually want to silently ignore?
Re: Parsers don't have to be complicated
#7I now use nom to write my parsers. Once you understand it, it’s simple and parsing complex data becomes a _fun_ puzzle. I recommend it.
Re: Parsers don't have to be complicated
#8The hardest thing about writing a parser is cognitively accepting what is going to be considered valid input. You can make the best parser that is fast and well specified but invariably someone will (ab)use it in an unexpected way.
Famous examples: despite so many initial good intentions, html tags don’t need to be closed, JSON numbers are too often encoded as strings, YAML can look like what most people expect or it can look progressively more like JSON… and on and on.
Re: Parsers don't have to be complicated
#9> LineReader splits input into lines, handles \n and \r\n, and trims the stray trailing \r that malformed input likes to leave behind Is there a common source of extra \r in malformed inputs, beyond those existing as part of \r\n? Or is this just a dig at Windows-style line endings? If there's something weird going on I think I'd rather fail loudly. > Bounding the inner scanner to a single line makes “run past the en…
End of line on Classic Mac is \r.
Re: Parsers don't have to be complicated
#10Earlier quoted context omitted.
Sure, start with \r\n, split on \n, now you have a stray \r at the end of every input.
But the preceding clause says it handles \r\n. If you're already handling \r\n, what remaining sources of \r are there, that you'd actually want to silently ignore?
Someone else (possibly you) already split on \n.