FFI: c/c++ struct on stack as an argument or return value

[Manuel M T Chakravarty]

Yuras,

I’m not convinced that the compiler is the right place for this kind of functionality. In fact, when we designed the Haskell FFI, we explicit decided against what you propose. There are a few reasons for this.

Firstly, compilers are complex beasts, and secondly, it takes a long time until a change in the compiler goes into production. Hence, as a general rule, it is advisable to move complexity from the compiler into libraries as this reduces compiler complexity. Libraries are less complex and changes can be rolled out much more quickly (it’s essentially a Hackage upload versus waiting for the next GHC and Haskell Platform release).

Thirdly, we have got the Haskell standard for a reason and modifying the compiler implies a language extension.

The design goal for the Haskell FFI was to provide the absolute minimum as part of the language and compiler, and to layer additional conveniences on top of that in the form of libraries and tools.

Have you considered the library or tool route?

Manuel

Yuras Shumovich <shumovichy at gmail.com>:
> Hi,
> 
> Right now ghc's FFI doesn't support c/c++ structures.
> 
> Whenever we have foreign function that accepts or returns struct by
> value, we have to create wrapper that accepts or returns pointer to
> struct. It is inconvenient, but actually not a big deal.
> 
> But there is no easy workaround when you want to export haskell function
> to use it with c/c++ API that requires structures to be passed by value
> (Usually it is a callback in c/c++ API. You can't change it's signature,
> and if it doesn't provide some kind of "void* userdata", then you are
> stuck.)
> 
> I'm interested in fixing that. I'm going to start with 'foreign import
> "wrapper" ...' stuff.
> 
> Calling conventions for passing c/c++ structures by value are pretty
> tricky and platform/compiler specific. So initially I'll use libffi for
> that (it will work when USE_LIBFFI_FOR_ADJUSTORS is defined, see
> rts/Adjustor.c). It will allow me to explore design space without
> bothering about low level implementation details. Later it could be
> implemented for native (non-libffi) adjustors.
> 
> Is anybody interested it that? I appreciate any comments/ideas.
> 
> Right now I don't have clear design. It would be nice to support plain
> haskell data types that are 1) not recursive, 2) has one constructor and
> 3) contains only c/c++ types. But it doesn't work with c/c++ unions. Any
> ideas are welcome.
> 
> An example how to use libffi with structures:
> http://www.atmark-techno.com/~yashi/libffi.html#Structures
> 
> Thanks,
> Yuras
> 
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs