Sven Panne <[EMAIL PROTECTED]> wrote,
> "Manuel M. T. Chakravarty" wrote:
> > Isn't there still a difference? When the C-library changes
> > (ie, you get a new version) and the definition of `Status'
> > changes to [...]
> > The IDL binding would produce wrong code, but the Green Card
> > binding would still be correct. Right? Or do I miss something?
>
> The Green Card binding will definitely be correct, but AFAIK the IDL
> binding will be not. This was one of my main motivations for preferring
> Green Card to H/Direct. To the IDL wizards: Is there a *simple* way to
> ensure consistency between header files and IDL sources, i.e. without
> perl/m4/awk/...? This is very important when you can't rely on a
> portable mapping of enumeration types to int. My usual example: AFAIK,
> in OpenGL there's no guarantee that your GL_xyz identifier is mapped
> to a certain int (via enum or cpp).
>
> BTW, both Green Card and IDL lose when an enumeration type gets an
> additional value, e.g. EXIT_WITH_LIMITED_SUCCESS :-)
I think, I may have a solution that does even the latter :-)
> And another point: I doubt that it is very feasible to automatically
> generate either Green Card sources or IDL from .h-files. Almost none
> of the header files I have seen use types very well, e.g. OpenGL uses
> GLenum for almost every enumeration type around, unistd.h uses int for
> the same purpose, [ list could be continued lazily... ]
The basic idea is to combine information from the C header
file with high-level type information from Haskell. And do
so with a "slim" tool (ie, less "new language" than Green
Card or an IDL). The main purpose of the tool would be to
Haskelize existing C libraries (ie, it is much less
ambitious than HDirect). But let's wait and see whether it
works the way I hope...
Manuel
