Proposal: GHC.Generics marked UNSAFE for SafeHaskell
Mon Oct 7 03:18:40 UTC 2013
I can't know for certain but I think I would bet money on "nothing".
Edward & David may know more about what actual use SafeHaskell is getting?
On Sun, Oct 6, 2013 at 5:46 PM, Johan Tibell <johan.tibell at gmail.com> wrote:
> What would break if we changed it to Unsafe?
> On Sun, Oct 6, 2013 at 2:32 PM, Ryan Newton <rrnewton at gmail.com> wrote:
> > Hi all,
> > We had a discussion on haskell-cafe, which only confirmed the
> > of "Eq" and "Ord". Fine. But if I instead want to define a SafeEq class
> > and instances based on GHC.Generics, then I can't have users writing
> > instances that lie about the structure of their types.
> > But as you can see this module is currently marked "Trustworthy":
> > I simply propose that this is changed to "Unsafe"! 
> > Context:
> > The bottom line is that I believe in the Safe-Haskell mission here, and I
> > want to be able to deliver practical libraries that give a strong
> > that types can't be broken. Currently, the LVish library has one big
> > in it because of this Eq/Ord limitation; the problem is documented here.
> > If we can provide incontrovertible Safe-Haskel guarantees, this is a
> > huge, qualitative difference compared to what's possible in the C++,
> > and MLs of the world. There are plenty of libraries that provide
> > like "deterministic parallelism" IFF the user does everything right and
> > breaks no rules (CnC, Pochoir, etc). But we can do better!
> > Best,
> > -Ryan
> >  Small detail... some of these bindings, like the class name
> > itself, will still need to be accessible from a Trustworthy library. I
> > propose GHC.Generics.Safe for that, following existing precedent.
> > On Sun, Oct 6, 2013 at 5:18 PM, Ryan Newton <rrnewton at gmail.com> wrote:
> >> Thanks for the responses all.
> >> I'm afraid the point about GHC.Generics got lost here. I'll respond and
> >> then rename this as a specific library proposal.
> >> I don't want to fix the world's Eq instances, but I am ok with requiring
> >> that people "derive Generic" for any data they want to put in an LVar
> >> container. (From which I can give them a SafeEq instance.)
> >> It's not just LVish that is in this boat.... any library that tries to
> >> provide deterministic parallelism outside of the IO monad has some very
> >> lines to walk. Take a look at Accelerate. It is deterministic (as
> long as
> >> you run only with the CUDA backend and only on one specific GPU...
> >> fold topologies may look different and non-associative folds may leak).
> >> Besides, "runAcc" does a huge amount of implicit IO (writing to disk,
> >> calling nvcc, etc)! At the very least this could fail if the disk if
> >> But then again, regular "pure" computations fail when memory runs
> out... so
> >> I'm ok grouping these in the same bucket for now. "Determinism modulo
> >> available resources."
> >>> A possible problem with marking "instance Eq" as an unsafe feature is
> >>> that many modules would be only Trustworthy instead of Safe.
> >> My proposal is actually more narrow than that. My proposal is to mark
> >> GHC.Generics as Unsafe.
> >> That way I can define my own SafeEq, and know that someone can't break
> >> by making a Generic instance that lies. It is very hard for me to see
> >> people should be able to make their own Generic instances (that might
> >> about the structure of the type), in Safe-Haskell.
> >>> That would go against my "every purely functional module is
> >>> safe because the compiler checks that it cannot launch the missiles"
> >>> understanding of Safe Haskell.
> >> Heh, that may already be violated by the fact that you can't use other
> >> extensions like OverlappingInstances, or provide your own Typeable
> >> instances.
> >>> Actually, Eq instances are not unsafe per se, but only if I also use
> >>> other module that assumes certain properties about all Eq instances in
> >>> scope. So in order to check safety, two independent modules (the
> >>> and the consumer of the Eq instance) would have to cooperate.
> >> I've found, that this is a very common problem that we have when trying
> >> make our libraries Safe-Haskell compliant -- often we want to permit and
> >> deny combinations of modules. I don't have a solution I'm afraid.
> > _______________________________________________
> > Libraries mailing list
> > Libraries at haskell.org
> > http://www.haskell.org/mailman/listinfo/libraries
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs