Data and Typeable for an opaque type
Hi, I'm working on an open source patch, but stumbled upon the following problem: I'm introducing a type that is basically a pointer in a FFI library, pointing to an opaque type (which I'm told is common practice). -- | An opaque type encapsulating a font in C. data Font_Opaque type Font = Ptr Font_Opaque The problem is that insertion in the current code would require this to be an instance of Data and Typeable. In this case (gloss library) I've not 100% understood why that's a requirement, I've been grepping (case-insensitive) for typeOf, constr, gfold, and I've not found any obvious use. Anyway, the rough-and-ready approach for this would be to manually define instances of Data and Typeable for the opaque type - my question is: what would sensible implementations look like for such a type? Thank you, Elise
data Font_Opaque type Font = Ptr Font_Opaque
[...]
Anyway, the rough-and-ready approach for this would be to manually define instances of Data and Typeable for the opaque type - my question is: what would sensible implementations look like for such a type?
Manual instances of those are usually highly questionable. While you probably won't blow up anything with a manual Data instance, a manual Typeable instance is in the critical danger zone alongside unsafeCoerce. First of all Ptr is already Typeable and for concrete types like Font_Opaque you can derive Typeable. That makes Font Typeable. If you need a Data instance for processing, then one way to get it is to build an isomorphism between Font and a regular Haskell type. Start by rewriting Font to be a newtype wrapper. Derive Data for the helper type and write the Data instance for Font in terms of it. This might save you a lot of work, or it may create even more work depending on the API you're depending on. Final alternative: You do what many of us have done many times. In some cases implementing a Haskell variant of a foreign library from scratch is more efficient than trying to deal with a clumsy C API. Often this is not an option, but when it is, it's usually a good one. Greets, Ertugrul
participants (2)
-
Elise Huard -
Ertugrul Söylemez