Simon Marlow <simonmar@microsoft.com> wrote,
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.
I agree. This is just beyond what can be done without requiring that the Haskell compiler generates C code or implements significant portions of a C compiler itself. Constants in C can be quite tricky: enum { VALUE0 = -1, VALUE1, VALUE2 }; typedef struct { int this; float that; } mystruct; #define EVIL_CONSTANT (VALUE1 + sizeof (mystruct)) C->Haskell implements part of a C compiler to get this right and hsc2hs uses a vanilla C compiler for that. Cheers, Manuel