I agree that this would be the cleaner solution. In fact.... I already have a typedef for the Double type in anticipation of using different sized floating point. Unfortunately I rely heavily on the BLAS linear algebra libraries. As long as I can type cast the haskell types in C to double or int where appropriate, I'm OK, at the expense of making some global changes to the code. Fortunately all my Blas interfaces are performed through typedefs. I'll have to look into this. Thanks again for the tip. Given that I'm making a lot of C calls through Haskell, with the unsafe tag in the import statement, does anyone have an idea of what kind of overhead I might still be incurring? I'm assuming that it's fairly minimal. The one call that has to be safe has a callback to a numerical Haskell function that is called repeatedly over every element in a potentially large matrix. I am also concerned about the performance of that procedure. Brian Hulley wrote:
Matthew Bromberg wrote:
3) The problem here is existing code. I don't want to add every function that I use into a class just to maintain simple polymorphism over closely related numeric types. This would take longer than just calling the coercion routines. It's funny how trivial stuff likes this gets irritating when you are writing a lot of code. Maybe I'm just in a bad mood or something.
It would be better to just use the Haskell numeric types in the first place ie replace all CInt, CDouble etc by Int, Double etc and change your C code accordingly to use HsInt, HsDouble instead of plain int, double etc. Hopefully this should just be a trivial matter of changing a few typedefs in a C header as long as the C functions don't refer to 'int' 'double' etc directly.
Regards, Brian.