It seems a good step to go. But I think cdata is nyacc dedicated, is it reasonable to separate it? You may add other backbends as extra package without separate the default cdata.
Best regards. On Sun, Dec 28, 2025, 08:09 Matt Wette <[email protected]> wrote: > Hi All, > > I have been working on NYACC for over 10 years now. I started with a > parser-generator > (lalr) and progressed to C parser (parse-c99) and then FFI helper > (ffi-helper). Lately I have > replaced the backend for the ffi-helper with a custom bytevector layer > (cdata). I have wondered > if I should split up this package. If so, it would likely be into the > following: > > 1) nyacc : the parser generator; no other guile-external dependencies > 2) guile-cdata: bytevector cover for C data, with arch-info; no other > guile-external dependencies > 3) guile-cparser : C parser, dependent on (1) nyacc and arch-info from (2) > 4) guile-ffi-helper: C code to guile FFI generator > > Thoughts? I'm looking for feedback from those who use any of the above. > > FYI, regarding the FFI helper, I have inserted a level of indirection so > that the FFI helper > can generate code for not only cdata, but also scheme-bytestructures and > bstructs, given > the plugins from github.com/mwette/guile-fhbe (ffi helper back-end). > I'm hoping I will not > have to provide support for the alternate backends. > (See dev-3.02 branch in github.com/mwette/nyacc for work-in-progress.) > > Matt > > >
