Re:Why Foreign Function Interfaces are not an easy answer (2...
by coldtea on Sunday January 16, 2022 @06:02PM
(#29961321)
>They already have it, and they call it a header file
Some languages already use that for the purpose, but it's an ill fit. It's meant for the internal parser of the language, so you need to parse C code (even if it's just the header file syntax). And it wasn't created with FFI in mind, in the first place.
What I propose is a file intended for others wanting to FFI, and thus trivial to parse (could be a schema for a format with ubiquitus parsers, like XML, JSON, YAML, TOML, and co).
That would have the benefit of:
(1) being cross-language (every language that exposes functions with C calling conventions could produce such a file to allow others to interface with it.
(2) being trivial to parse and integrate with ffi facilities of different languages (e.g. ctypes)
(3) being extensible beyond the C-header files give (e.g. metadata about usage, or valid int ranges, even function documentation, etc).
Some languages already use that for the purpose, but it's an ill fit. It's meant for the internal parser of the language, so you need to parse C code (even if it's just the header file syntax). And it wasn't created with FFI in mind, in the first place.
What I propose is a file intended for others wanting to FFI, and thus trivial to parse (could be a schema for a format with ubiquitus parsers, like XML, JSON, YAML, TOML, and co).
That would have the benefit of:
(1) being cross-language (every language that exposes functions with C calling conventions could produce such a file to allow others to interface with it.
(2) being trivial to parse and integrate with ffi facilities of different languages (e.g. ctypes)
(3) being extensible beyond the C-header files give (e.g. metadata about usage, or valid int ranges, even function documentation, etc).