Deprecating Safe Haskell, or heavily investing in it?

Chris Smith cdsmith at
Wed Dec 28 03:33:04 UTC 2022

Thanks for writing this up!

I was a user of SafeHaskell briefly in 2011-2012, and it certainly has
theoretical benefits.  That said, though, I agree that the balance of the
cost-benefit analysis is solidly against it, and I would much rather ease
the burden of GHC and library development than continue to maintain a
burdensome niche feature with limited users.

That said, I think some of the comments in this thread are unnecessarily
dismissive of SafeHaskell's usefulness and correctness.  So here are a few
things worth keeping in mind:

1. The strict type safety aspect of SafeHaskell is, in fact, the mechanism
that makes SafeHaskell effective at controlling effects through limited IO
access.  You simply cannot have the latter without the former.  Generalized
newtype deriving, for example, is incompatible with SafeHaskell precisely
because it can be used to break restricted IO access. It looks like a lot
of the responses here ignore that SafeHaskell did a lot of work to make
runtime-cost-free safe execution reliable, then make hand-wavy references
to other systems that don't do any of that, and use that as a basis for
asserting distrust in SafeHaskell.  That's entirely unfair.
2. The assertion that safety in SafeHaskell depends on the correctness of a
bunch of libraries assertions about their safety reveals a fundamental lack
of understanding of how SafeHaskell works.  Safety is inferred
compositionally from the source code and the safety of the modules it uses,
and a source code annotation about safety can never compromise the safety
guarantees of SafeHaskell.  The only thing that can compromise safety is a
misplaced trust decision.  Trust decisions are not in the source code at
all.  They are made outside the source by running `ghc-pkg trust`.

This conversation reminds me of a parable I encountered somewhere, in which
someone declares "I don't understand why this decision was ever made, and I
we should change it", and someone responds, "No, if you don't understand
the decision was made, then you don't know enough to change it.  If you
learn why it was decided that way in the first place, then you will have
the understanding to decide whether to change it."  Just like in the
parable, I am not disagreeing with the idea of deprecating SafeHaskell, but
I am skeptical that the decision should be made on the basis of
misrepresentations and crude analogies that completely miss what's unique
and interesting about SafeHaskell in the first place.

On Tue, Dec 27, 2022, 10:10 AM Hécate <hecate at> wrote:

> Hi everyone, and happy holidays.
> I am looking into whether or not Safe Haskell is still worth maintaining.
> Currently there are two sides on which Safe Haskell hurts us:
> 1. GHC Development
> 2. Library development
> For point n°1: You can easily take the measure of what Safe Haskell
> raises in GHC as of today by visiting the bug tracker¹ and see that for
> example Unboxed Types cannot be used because their home modules
> (GHC.Prim and GHC.Types) are marked as Unsafe. Moreover, interactions
> between GHC2021 and Safe make the latter quite unpleasant to work with².
> Regarding point n°2: Safe Haskell is badly integrated within our
> existing frameworks for API compatibility. Neither the PVP nor the
> extension's documentation mention compatibility, or define what stance
> we should take. Thus we are bound to fight on the letter versus the
> spirit of the PVP (which is not an unreasonable debate since there is no
> formalism anywhere). This provokes debates without clear resolution
> beyond "Friend don't let friends use {-# Safe #-}"³
> Now I am not saying that Safe Haskell does not bring any kind of good
> idea, far from it.
> However there are two things that live inside Safe Haskell that would
> benefit from being separated:
> 1. Strict type-safety
> 2. Restricted IO
> A lot of the public use-cases of Safe Haskell seem to be on the
> "Restricted IO", such as Lambdabot and other code evaluators out there.
> It's a fairly reasonable feature, I'd even say it's something that we
> should be publicising more when speaking about GHC's more advanced
> features. However, "Strict type-safety" seems to be the root of many
> problems that we encounter downstream. A lot of it stems from
> GeneralizedNewtypeDeriving being marked as unsafe (under point 1), which
> is fair enough, but we've had DerivingVia not marked as Safe until May
> 2021, which reveals a big problem: Options have to be marked as
> forbidden under Safe to be caught, which leaves a lot of work to the
> human factor of GHC development.
> Now, there are two options (convenient!) that are left to us:
> 1. Deprecate Safe Haskell: We remove the Safe mechanism as it exists
> today, and keep the IO restriction under another name. This will
> certainly cause much joy amongst maintainers and GHC developers alike.
> The downside is that we don't have a mechanism to enforce "Strict
> type-safety" anymore.
> 2. We heavily invest in Safe Haskell: This is the option where we amend
> the PVP to take changes of Safety annotations into account, invest in
> workforce to fix the bugs on the GHC side. Which means we also invest in
> the tools that check for PVP compatibility to check for Safety. This is
> not the matter of a GSoC, or a 2-days hackathon, and I would certainly
> have remorse sending students to the salt mines like that.
> I do not list the Status Quo as an option because it is terrible and has
> led us to regularly have complaints from both GHC & Ecosystem libraries
> maintainers. There can be no half-measures that they usually tend to
> make us slide back into the status quo.
> So, what do you think?
> ¹
> ²
> ³
> --
> Hécate ✨
> 🐦: @TechnoEmpress
> IRC: Hecate
> WWW:
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the ghc-devs mailing list