Open edsko opened 1 month ago
As an example of the kind of high-level binding we might want to generate, consider
void resample(
int32_T *res_m_num_valid_samples,
cint16_T res_m_iq_int[30720000],
int64_T res_m_old_rate,
int64_T res_m_new_rate,
cint16_T res_m_iq_resampled_int[30720000]
);
for which we might want to generate
resample ::
Vector (Complex Int16)
-> Int64
-> Int64
-> IO (Int, Vector (Complex Int64))
Perhaps another source of inspiration for specifying expected types is to look at interface description languages, such as https://learn.microsoft.com/en-us/windows/win32/rpc/the-idl-file .
One thing we should probably think about is that when we implement these customization options for high-level bindings (and indeed also the standard set of defaults, see #32), we probably need to make it possible to the mapping from the low-level binding to the chosen high-level binding depend on the target architecture.
Apparently greenfield
does some of this also; tracking taking a look at that separately at https://github.com/well-typed/hs-bindgen/issues/62 .
The generation of the high-level API is much more open to interpretation (of the C header) than the low-level API. Things to think about here are
char*
correspond toString
,ByteString
,Text
, something else?int
correspond toInt
,Natural
, or perhaps evenBool
?int[]
correspond to a vector, a mutable vector, a list, ...?as
Complex Int16
?NULL
terminatedint*
int*
meant to be a pointer to a singleint
, or to an array?and there are undoubtedly more.
There are also some Haskell-specific things to think about ( some of these need to be considered for the low-level bindings also):
as well as
ghc
-specific options, such asIO
.It would also be a good to take a look at exactly what Rust
bindgen
offers here, and see what's relevant for us:Copy
andClone
,Debug
,Default
). Probably also relevant.It also supports marking types as
#[must-use]
; we're tracking this as its own issue at Haskell equivalent of Rust's must-use?.Not only do we need to think about all the choices
hs-bindgen
need to make, but also how we can give users the ability to influence (customize) those options. Options we could consider arehs-bindgen
as a library, with customizations in normal Haskell codeThe downside of the first two approaches is that we might end up with users having to learn bespoke syntax again (which we consider to be a disadvantage of tools such as
c2hs
), making the third option quite appealing. It does however mean users might need to compile their own custom version of the tool, but for power users who need to generate a lot of bindings this might be worth it.