

Parser combinator library in C - wbhart
https://github.com/wbhart/Cesium3/tree/combinators

======
Jacobi
I don't know why it uses a garbage collector when simple reference counting
would suffice. Also I hate libraries with global states/variables like this
one ...

~~~
hythloday
How would you implement refcounting in the presence of longjmp? I don't see a
graceful way to do it.

~~~
simias
I don't like C libraries that use longjmp for error handling. It's like
killing a fly with a bazooka. There are some cases when longjmp is useful of
course, but If you want proper exceptions, use a language that supports them.

~~~
rcfox
The OP is doing awesome stuff and sharing it with the world, and you want to
criticize an implementation detail?

Bikeshedding like this isn't useful to anyone.

~~~
Jacobi
I appreciate the OP's efforts, certainly sharing code is a good thing. And one
of the benefits of the sharing is to get a lot of feedback. Criticizing
implementation details is important to spot, discuss and hopefully fix
potential problems.

~~~
hythloday
But the only actionable advice you can take away from the criticism is
"rewrite it in C++". I don't think that's in any way useful and I don't think
it should be made.

~~~
dllthomas
Right - "Don't use longjmp, do X in C instead" would have been a useful
comment (particularly with example code). "Don't use longjmp, use C++ instead"
is much less useful.

~~~
simias
I agree that my comment was a bit harsh, but that's not what I said. I said
that if he wanted exceptions he shouldn't have used C.

As for the alternatives, well return values never killed anyone, did they? You
can use gotos to simplify the control flow within the functions. Other than
that, there really isn't much to explain.

I don't like longjmp because I never expect them in C. I never think "hey, the
control flow might jump to some point 20 stack frames above at any moment when
I enter this library". And then I use mutexes. Cue the drama. You can't even
protect yourself from the stack unwinding with handler-case or try ...
catch/except.

------
bsaul
could anyone explain the use for this library ?

~~~
wbhart
The major parser libraries that I could find don't allow adding syntax at
runtime or to add operators to the expression hierarchy at runtime. Many
(though not all) of them also make it difficult to do custom error reporting.
These were my major motivations.

~~~
_delirium
Ah right, interesting use-case. I usually think of combinator parsing's
advantages versus table-driven parsing (e.g. LALR) being primarily its
expressiveness (and amenability to a functional-programming style), but it has
a nice runtime-modifiable aspect as well.

I wonder how hard it'd be to build a runtime-modifiable table-driven parser,
though. Assuming table compilation is fast enough, the most straightforward
approach might be to just link in the grammar-compilation code so it's
available at runtime, and rebuild the table each time a modification is made.
I don't think you'd want to be doing complex incremental surgery on a table-
driven parser, but you might not need to.

------
jheriko
nice, but would be better to have something simpler that doesn't rely on
various libraries and features that are typically forbidden in high
performance environments.

incidentally almost every memory leak I deal with comes from not being allowed
to allocate my own memory and having to fiddle around with gc and refcount
rubbish.

I have written whole non-trivial games with no detectable leaks.

~~~
wbhart
Could you provide some more information about "features that are typically
forbidden in high performance environments".

Probably you want a parser expression grammar with a packrat parser if you
really want speed anyway.

At the moment I am not smart enough to see how to implement combinators in C
in an elegant way without GC of some form. But I'll think about it. Maybe
something will occur to me.

Patches are welcome of course.

