right now there is duplication as the enum backend value is still
present- need to find out if it's OK to make a breaking change for
anyone who is for reasons known only to themselves chekcing which
backend enum value is one a parser they may have created and compiled...

vtable pointer, clean up some of the redundant information in backend
with params struct

HParserBackendWithParams

compared to with strnig functions. WIP, feedback requested

but ready for review

committing now because of harddrive making a bad sound again.

cleanup

hard drive sounded bad. TODO includes free and copy updated and a bunch
of refactoring / redesign of the solution

"glr(1)" and call compile for the appropriate backend. Needs clean up
and refactor, and tests, but it compiles and my hard-drive is
periodically making threatening noises...

that we also check to confirm both engines have consume the same number
of tokens (and thus have actually both arrived at the same state for the
same partial input stream)

Using _POSIX_C_SOURCE in the middle of a header is incorrect and may work unreliably because of multiple-include guards

fixes issue #83

hammer/hammer#83

doh! fixes issue 92 again.

tentative commit. this should solve issue 92, but isn't working, yet.

the idea is to taint any memoized follow set that hit a recursive loop,
directly or indirectly. the recursive calls (h_follow_rec) are allowed to use
these intermediates, but propagate the taint. the top-level routine (h_follow)
places the original taint on its result and may remove it at the end. it will
not return memoized results that are tainted (but compute them afresh).

without it, our test for issue 92 is no good (will always pass).
we could probably officially put it back if we simplify "dead"
symbols (that have no productions) out of the grammar beforehand.

there is a case where fs can be empty: when reducing by lhs would lead to
certain parse failure, by means of h_nothing_p() for instance.

fixes issue 83.

cf.
hammer/hammer#83