Log in to h4cker, then connect Hacker News to publish comments.
EQeqvinox1 jam yang lalu
> 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 jam yang lalu
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 jam yang lalu
Now all it needs is a parser in 'examples/' that parses EBNF grammars and emits a parser in terms of these combinators.
ZOzombot3 jam yang lalu
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.