#5529: Newtypes with hidden constructors cannot be passed as FFI arguments
-----------------------------------+----------------------------------------
Reporter: mikhail.vorozhtsov | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 7.3
Keywords: | Testcase:
Blockedby: | Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-----------------------------------+----------------------------------------
Comment(by simonmar):
Replying to [comment:11 mikhail.vorozhtsov]:
> Replying to [comment:10 simonmar]:
> > I think your point (1) is saying that even if we know that `CTime ==
Int64`, what the programmer actually needs to know is that `CTime ==
time_t`, correct?
> Yes. And, more importantly, the programmer needs a way to ensure that
`CTime == time_t` ''automatically'' at compile time, because we can't
really expect people to recheck that equality by hand every time a new
version of the library is released/used. This hypothetical machinery must
be able to handle multiple levels of wrapping, like `CTime -> X1 -> X2 ->
Int64`.
This goes way beyond the original ticket, and I must admit I'm having
trouble following your arguments.
The fact remains that allowing an abstract `newtype` to be used in an FFI
declaration breaks the abstraction, so we can't allow that. If you want
to propose an alternative mechanism that would fix this problem, please go
head - but I suggest this ticket is not the right place (a wiki page would
be better).
> My other (original) concern is that exporting a constructor does not
only reveal the representation of the type, but also, obviously, gives
third party non-FFI code a way to construct instances of the type. For
CTime it may be ok, but think about flag types, which are allowed to have
only limited number of bits set (or, even worse, only limited number of
combinations of set bits).
But you want to give clients the ability to call arbitrary foreign
functions that return the type! Allowing them to construct instances in
Haskell is no worse than that.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5529#comment:12>
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
