On Wed Dec 17, 2025 at 9:23 AM CET, Diogo wrote: > > We have a simple CRUNCH file called bytevec-impl.scm, which contains these two > procedures: > >[...]
Sorry, this is too much at once and I don't have the time to dig through all of this, but I have a few suggestions. First, passing -DCRUNCH_EMBEDDED shouldn't be necessary, if it is to compile properly, we probably have to add it. The error message you get is that you are missing support code from the runtime part of the "crunch" module (crunch.so) which is needed to convert CRUNCH numvector wrappers into something CHICKEN understands at the FFI level. This may be considered a bug. The "wrappers" generated by chicken-crunch present to CHICKEN code something that looks like C to its FFI, CRUNCH and CHICKEN code is not interchangable at the Scheme level, so CRUNCH bytevectors are not CHICKEN bytevectors, CHICKEN sees CRUNCH code as C and the FFI handles only those types. Using the "crunch" macro to embed statically typed Scheme into dynamically typed code is an attempt to keep the illusion of all code being interoperable up to a certain extent, but that is all and that sort of works as it has full control over how the generated C is embedded. The various combinations of how Scheme, C and CRUNCHed Scheme and CHICKEN FFI glue code are interacting are many and add too much complexity (I already regret providing wrapper modules...), so I'm reluctant to explore how to make wrappers completely watertight. The two usage scenarios that CRUNCH is intended for is a) standalone code, b) code embedded via the "crunch" macro. I'm not even sure the compiler and type inferencer work reliably, not even speaking of the more involved optimizations like lambda-lifting. cheers, felix
