Deprecating Safe Haskell, or heavily investing in it?

Wed Dec 28 05:14:39 UTC 2022

I hope that some effort can be expended to specifically identify what
changes would be necessary to make Safe Haskell work consistent with
its name. Only then can a reasoned decision about how to proceed be
made. Also, rejecting the status quo implies that making a decision is
a high priority. Is it really that urgent? If Safe Haskell isn't being
used much, then why hurry to fix it or kill it?

On Tue, 2022-12-27 at 20:33 -0700, Chris Smith wrote:
> 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 glitchbra.in> 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?
> > 
> > 
> > ¹ 
> > https://gitlab.haskell.org/ghc/ghc/-/issues/?label_name%5B%5D=Safe%20Haskell
> > 
> > ² https://gitlab.haskell.org/ghc/ghc/-/issues/19605
> > 
> > ³ https://github.com/haskell/directory/issues/147
> > 
> > 
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs