Log in to h4cker, then connect Hacker News to publish comments.
EQeqvinoxhace 1 hora
> 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.)
SPsphhace 6 horas
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.
RORossBencinahace 3 horas
Now all it needs is a parser in 'examples/' that parses EBNF grammars and emits a parser in terms of these combinators.
ZOzombothace 3 horas
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.