4 ms·

Thanks! I'll have to look into this some more but if anyone can volunteer the information, these questions come to mind: - What situations could cause the look

Thanks! I'll have to look into this some more but if anyone can volunteer the information, these questions come to mind: - What situations could cause the look-ahead to be unbounded? - How does the Go parser's implementation differ from those of the languages I'd previously listed which all also have angle brackets for comparison (and bit shifts, as another commenter pointed out) while apparently avoiding unbounded look-ahead? - What challenges does the Go parser present when trying to adapt it to follow patterns more like those from the other languages' parsers? - I'm assuming "unbounded" here doesn't mean "it could take unlimited time" but rather "it could incur non-negligible compile-time penalties;" do the benefits of a slightly-quicker compilation (which has nominally no impact on runtime performance) outweigh improved readability?

ogogmad 6y ago
Unlimited lookahead parsers are not necessarily inefficient in terms of time. PEGs for instance run in linear time, but use up linear memory, which is the problem: https://en.wikipedia.org/wiki/Parsing_expression_grammar https://en.wikipedia.org/wiki/Parsing_expression_grammar > - How does the Go parser's implementation differ from those of the languages I'd previously listed which all also have angle brackets for comparison (and bit shifts, as another commenter pointed out) while apparently avoiding unbounded look-ahead? I think parsing Java or C++ requires unlimited lookahead.
- echlebek 6y ago
  https://blog.reverberate.org/2013/08/parsing-c-is-literally-undecidable.html https://blog.reverberate.org/2013/08/parsing-c-is-literally-...