On Wed, Jul 01, 2009 at 02:22:36PM -0300, Maurício wrote:
Yeah, I'm not suggesting going via Storable (for all those reasons), just extending the FFI to say tuples of FFI types get passed as the corresponding C ABI structs. All the magic to match the current platform C ABI then lives in the compiler.
Agree. The tuples idea is far better than my first sugestion on Storable instances.
I was only half-serious in suggesting this btw, though as far as I can see it should actually work. It doesn't help with unions of course and it adds complexity to the compiler.
:(
The only known case I have of this beeing important is on GNU GSL, where the complex functions use a complex type defined as a struct (with a size 2 array as the only member). This actually just emulates the 'complex' type of C99, I'm almost sure.
I don't know whether it is required that Complex be represented in such a way though.
Do you imagine an objection on creating a ticket asking for something like CComplex on Foreign.C.Types?
No, I would like it. Also add a 'CBool' that maps to the calling convention for _Bool while you are at it. You would need CComplexFloat and CComplexDouble... or perhaps we should just define that 'Complex CFloat' and 'Complex CDouble' are FFI-able types in the obvious way. that is probably better actually. Another FFI related extension I have wanted at times is making user defined types that derive an 'Enum' instance FFI-able, with an 'int' calling convention, translated via toEnum and fromEnum. -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/