Yes, I am persuaded that hard-coded datatypes tend to be bad in this situation. The way hsc2hs deals with constants is quite good, and it is certainly a better, more flexible, approach. However, I do have some hesitation in relying on yet another pre-processing tool, with yet another "little language" outside of Haskell itself.
Of course hsc2hs does more than just filling in constants, but for just that one task, I wonder if we should be extending the primitive FFI mechanism itself. For instance, we already have "foreign label", so what about perhaps "foreign value":
foreign value "F_GETFL" fGetFL :: CInt
This is just off the top of my head, so I'm probably missing some subtleties. What do people think of this idea? Are there some real killer situations which would make it impossible?
Uh-oh! The return of litlits! But seriously, this approach pollutes the language-independence of the low level FFI, unless you add an extra language descriptor to the declaration. It's also awkward to implement unless you compile via C - you couldn't implement this using a dumb preprocessor, for example. The preprocessor approach seems to be the lesser of several evils. Cheers, Simon