#7204: Use a class to control FFI marshalling
---------------------------------+------------------------------------------
Reporter: simonpj | Owner:
Type: feature request | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 7.4.2
Keywords: | Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown | Testcase:
Blockedby: | Blocking:
Related: |
---------------------------------+------------------------------------------
Comment(by igloo):
Two things occur to me:
Currently, if a library defines a type `T`, uses it with the FFI, but
exports `T` abstractly, then users of the library can't use `T` with the
FFI. With this proposal, it would not be possible to not export the
instance. I'm not sure if that's really a problem, and there's always the
workaround of manually marshaling for the library-internal FFI calls.
The other issue is that a lot of hackage would suddenly become dependent
on ATs. Actually, provided library writers use "deriving Marshal" wherever
possible, correct code will work if the Haskell implementation just
ignores the deriving clause and removes newtype wrappers at FFI calls, but
ideally we wouldn't rely on such a workaround.
So I wonder what the state of ATs is? Is there a simple and correct spec
for the extension that it would be reasonable to require Haskell
implementations to implement?
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7204#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
