Log in to h4cker, then connect Hacker News to publish comments.
EQeqvinox1 時間前
> Flex or Bison generated code is also hard to maintain plus it complicates builds.
This is, in all honesty, a solved problem in any reasonable build system. (And I have little patience left for people making life hard for themselves through their own choices.)
SPsph6 時間前
Beautiful work! I'm not even gonna wonder if any of it was AI-generated, because the code is clearly crafted meticulously by an experienced C engineer, very readable, and shorter than I expected.
RORossBencina3 時間前
Now all it needs is a parser in 'examples/' that parses EBNF grammars and emits a parser in terms of these combinators.
ZOzombot3 時間前
So many parser combinators operate on bytes assuming ASCII input only. I'd be more interested in a parser combinator lib that has UTF-8 decoding already abstracted away, operating on `wchar_t`, or even polymorphic input stream element types.
Comments
4 preview comments · loading full threadLog in to h4cker, then connect Hacker News to publish comments.
> Flex or Bison generated code is also hard to maintain plus it complicates builds. This is, in all honesty, a solved problem in any reasonable build system. (And I have little patience left for people making life hard for themselves through their own choices.)
Beautiful work! I'm not even gonna wonder if any of it was AI-generated, because the code is clearly crafted meticulously by an experienced C engineer, very readable, and shorter than I expected.
Now all it needs is a parser in 'examples/' that parses EBNF grammars and emits a parser in terms of these combinators.
So many parser combinators operate on bytes assuming ASCII input only. I'd be more interested in a parser combinator lib that has UTF-8 decoding already abstracted away, operating on `wchar_t`, or even polymorphic input stream element types.