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/ _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
