Generalized Newtype Deriving not allowed in Safe Haskell
Simon Peyton Jones
simonpj at microsoft.com
Fri Apr 10 08:48:52 UTC 2015
| prefer, such as only exporting the Coerce instance if all the
| constructors are exported, it seems that the ship sailed on these
Coercible is relatively recent; I don't think we should regard it as cast in stone.
But yes, the Coerbible instance of a newtype is only available when the data constructor for the newtype is lexically in scope.
Simon
| -----Original Message-----
| From: davidterei at gmail.com [mailto:davidterei at gmail.com] On Behalf Of
| David Terei
| Sent: 10 April 2015 09:38
| To: Simon Peyton Jones
| Cc: Omari Norman; haskell Cafe; ghc-devs at haskell.org
| Subject: Re: Generalized Newtype Deriving not allowed in Safe Haskell
|
| I'll prepare a patch for the userguide soon.
|
| As for something better, yes I think we can and should. It's on my todo
| list :) Basically, the new-GND design has all the mechanisms to be
| safe, but sadly the defaults are rather worrying. Without explicit
| annotations from the user, module abstractions are broken. This is why
| we left GND out of Safe Haskell for the moment as it is a subtle and
| easy mistake to make.
|
| If the module contained explicit role annotations then it could be
| allowed. The discussion in
| https://ghc.haskell.org/trac/ghc/ticket/8827 has other solutions that I
| prefer, such as only exporting the Coerce instance if all the
| constructors are exported, it seems that the ship sailed on these
| bigger changes sadly.
|
| Cheers,
| David
|
| On 9 April 2015 at 00:56, Simon Peyton Jones <simonpj at microsoft.com>
| wrote:
| > There is a long discussion on
| > https://ghc.haskell.org/trac/ghc/ticket/8827
| > about whether the new Coercible story makes GND ok for Safe Haskell.
| > At a type-soundness level, definitely yes. But there are other
| > less-clear-cut issues like “breaking abstractions” to consider. The
| > decision on the ticket
| > (comment:36) seems to be: GND stays out of Safe Haskell for now, but
| > there is room for a better proposal.
| >
| >
| >
| > I don’t have an opinion myself. David Terei and David Mazieres are in
| > the driving seat, but I’m sure they’ll be responsive to user input.
| >
| >
| >
| > However, I think the user manual may not have kept up with #8827.
| The
| > sentence “GeneralizedNewtypeDeriving — It can be used to violate
| > constructor access control, by allowing untrusted code to manipulate
| > protected data types in ways the data type author did not intend,
| > breaking invariants they have established.” vanished from the 7.8
| > user manual (links below). Maybe it should be restored.
| >
| >
| >
| > Safe Haskell aficionados, would you like to offer a patch for the
| manual?
| > And maybe also a less drastic remedy than omitting GND altogether?
| >
| >
| >
| > Simon
| >
| >
| >
| > From: Omari Norman [mailto:omari at smileystation.com]
| > Sent: 09 April 2015 02:44
| > To: haskell Cafe
| > Subject: Generalized Newtype Deriving not allowed in Safe Haskell
| >
| >
| >
| > When compiling code with Generalized Newtype Deriving and the
| > -fwarn-unsafe flag, I get
| >
| >
| >
| > -XGeneralizedNewtypeDeriving is not allowed in Safe Haskell
| >
| >
| >
| > This happens both in GHC 7.8 and GHC 7.10.
| >
| >
| >
| > I thought I remembered reading somewhere that GNTD is now part of the
| > safe language? The GHC manual used to state that GNTD is not allowed
| > in Safe
| > Haskell:
| >
| >
| >
| > https://downloads.haskell.org/~ghc/7.6.3/docs/html/users_guide/safe-
| ha
| > skell.html#safe-language
| >
| >
| >
| > But this language on GNTD not being part of the safe language was
| > removed in the 7.8 manual:
| >
| >
| >
| > https://downloads.haskell.org/~ghc/7.8.2/docs/html/users_guide/safe-
| ha
| > skell.html#safe-language
| >
| >
| >
| > The GHC release notes don't say anything about this one way or the
| other.
| > Thoughts?
| >
| >
| > _______________________________________________
| > ghc-devs mailing list
| > ghc-devs at haskell.org
| > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
| >
More information about the ghc-devs
mailing list