Hello Dmitry :) Thanks for this patch series. As you can see it was a bit daunting to review :) Sorry for the delay.
I think the xattr work is probably most appropriate for a separate library. Guile doesn't currently bundle any modules that use the dynamic FFI to bind C functions. You can understand my hesitation to take responsibility for ABI mismatches between Guile and a third-party library that I don't know a lot about. I think that a separately packaged library would do a better job. The (system foreign declarative) work looks really interesting. We definitely need a higher-level FFI. I have some opinions here but I don't have the cycles to hash them out :/ Basically I have had good experiences with LuaJIT's ffi recently and would like to try something like that some time. It's especially wonderful for data. I also think that in Guile we should have the ability to tag bytevectors with a type, so that we can access their fields in a nice way, so they print nicely, and all that with just a couple words overhead per struct. Maybe in some cases we can even optimize it out. It would be nice to have a path towards no-allocation FFI data access in many cases. But your code is really great too. Different from what I was thinking about, but well done. That makes me think that we should not incorporate anything into Guile at this time; rather we should encourage people to experiment and build nice third-party high-level FFIs as librarys, and encourage others to use those libraries, possibly even by just copying them into users' source trees, to minimize dependency hell. What do you think? Andy
