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
_______________________________________________
ghc-devs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/ghc-devs
