On Wed, Dec 17, 2025 at 11:41:32AM +0100, Felix Winkelmann wrote: > 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.
Ok, that makes sense. > 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. Understood. In that case, I will change my code to use option (b) and completely drop the use of the wrapper libraries. Also, it might indeed be a good idea to get rid of the -emit-wrappers flag because soon or later someone like me will try to use it :-D Thanks for the replies. Best, -Diogo
