simonmar at microsoft.com
Fri Dec 1 10:32:27 EST 2000
> 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.
More information about the FFI