So the hard parts are: - the native code generators - native adjustor support (rts/Adjustor.c) Everything else is relatively striaghtforward: we use libffi for adjustors on some platforms and for GHCi, and the LLVM backend should be quite easy too. I would at least take a look at the hard bits and see whether you think it's going to be possible to extend these to handle struct args/returns. Because if not, then the idea is a dead end. Or maybe we will need to limit the scope to make things easier (e.g. only integer and pointer fields). Cheers, Simon On 18/03/2014 17:31, Yuras Shumovich wrote:
Hi,
I thought I have lost the battle :) Thank you for the support, Simon!
I'm interested in full featured solution: arguments, return value, foreign import, foreign export, etc. But it is too much for me to do it all at once. So I started with dynamic wrapper.
The plan is to support structs as arguments and return value for dynamic wrapper using libffi; then implement native adjustors at least for x86_64 linux; then make final design decision (tuple or data? language pragma? union support? etc); and only then start working on foreign import.
But I'm open for suggestions. Just let me know if you think it is better to start with return value support for foreign import.
Thanks, Yuras
On Tue, 2014-03-18 at 12:19 +0000, Simon Marlow wrote:
I'm really keen to have support for returning structs in particular. Passing structs less so, because working around the lack of struct passing isn't nearly as onerous as working around the lack of struct returns. Returning multiple values from a C function is a real pain without struct returns: you have to either allocate some memory in Haskell or in C, and both methods are needlessly complex and slow. (though allocating in Haskell is usually better.) C++ code does this all the time, so if you're wrapping C++ code for calling from Haskell, the lack of multiple returns bites a lot.
In fact implementing this is on my todo list, I'm really glad to see someone else is planning to do it :-)
The vague plan I had in my head was to allow the return value of a foreign import to be a tuple containing marshallable types, which would map to the appropriate return convention for a struct on the current platform. Perhaps allowing it to be an arbitrary single-constructor type is better, because it allows us to use a type that has a Storable instance.
Cheers, Simon