How to deal with semi-standard types.

[phadej]

Like uint64_t (from <stdint.h>) or e.g. clock_t. These are probably typedefs in the standard library. As long as C compiler is considered, it would just expand these and don't see an abstraction. (Not sure what happens as library segfaults, #131(. But arguably in Haskell bindings it could make sense to preserve the abstraction and use Word64 and CClock respectively.

hs-bindgen could have a mode for host preprocessing (generating target-independent .hsc files, i.e. doing what people do now manually); then library writers won't expose dependency on their librarary users. Personally that's the mode which I'd use. In that mode preserving an abstraction is probably a must have.

[phadej]

In #131 we still see uint64_t fields as typedefs. So this will depend on how we will deal with typedefs (are they types or newtypes or whether it depends).

[edsko]

Turns out we do see uint64_t and clock_t; see #176. That doesn't of course answer the question of how to deal with these; I guess we should have a prelude of standard types, which can be extended. I can take a first stab at this.

[edsko]

Closing; tracking this work in #293 instead.