<div dir="ltr"><div dir="auto">Thanks for writing this up!<div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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:</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto">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`.</div><div dir="auto"><br></div><div dir="auto">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. </div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Dec 27, 2022, 10:10 AM Hécate <<a href="mailto:hecate@glitchbra.in" rel="noreferrer" target="_blank">hecate@glitchbra.in</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi everyone, and happy holidays.<br>
<br>
I am looking into whether or not Safe Haskell is still worth maintaining.<br>
<br>
Currently there are two sides on which Safe Haskell hurts us:<br>
<br>
1. GHC Development<br>
2. Library development<br>
<br>
For point n°1: You can easily take the measure of what Safe Haskell <br>
raises in GHC as of today by visiting the bug tracker¹ and see that for <br>
example Unboxed Types cannot be used because their home modules <br>
(GHC.Prim and GHC.Types) are marked as Unsafe. Moreover, interactions <br>
between GHC2021 and Safe make the latter quite unpleasant to work with².<br>
<br>
Regarding point n°2: Safe Haskell is badly integrated within our <br>
existing frameworks for API compatibility. Neither the PVP nor the <br>
extension's documentation mention compatibility, or define what stance <br>
we should take. Thus we are bound to fight on the letter versus the <br>
spirit of the PVP (which is not an unreasonable debate since there is no <br>
formalism anywhere). This provokes debates without clear resolution <br>
beyond "Friend don't let friends use {-# Safe #-}"³<br>
<br>
Now I am not saying that Safe Haskell does not bring any kind of good <br>
idea, far from it.<br>
<br>
However there are two things that live inside Safe Haskell that would <br>
benefit from being separated:<br>
<br>
1. Strict type-safety<br>
<br>
2. Restricted IO<br>
<br>
A lot of the public use-cases of Safe Haskell seem to be on the <br>
"Restricted IO", such as Lambdabot and other code evaluators out there.<br>
<br>
It's a fairly reasonable feature, I'd even say it's something that we <br>
should be publicising more when speaking about GHC's more advanced  <br>
features. However, "Strict type-safety" seems to be the root of many <br>
problems that we encounter downstream. A lot of it stems from <br>
GeneralizedNewtypeDeriving being marked as unsafe (under point 1), which <br>
is fair enough, but we've had DerivingVia not marked as Safe until May <br>
2021, which reveals a big problem: Options have to be marked as <br>
forbidden under Safe to be caught, which leaves a lot of work to the <br>
human factor of GHC development.<br>
<br>
Now, there are two options (convenient!) that are left to us:<br>
<br>
1. Deprecate Safe Haskell: We remove the Safe mechanism as it exists <br>
today, and keep the IO restriction under another name. This will <br>
certainly cause much joy amongst maintainers and GHC developers alike. <br>
The downside is that we don't have a mechanism to enforce "Strict <br>
type-safety" anymore.<br>
<br>
2. We heavily invest in Safe Haskell: This is the option where we amend <br>
the PVP to take changes of Safety annotations into account, invest in <br>
workforce to fix the bugs on the GHC side. Which means we also invest in <br>
the tools that check for PVP compatibility to check for Safety. This is <br>
not the matter of a GSoC, or a 2-days hackathon, and I would certainly <br>
have remorse sending students to the salt mines like that.<br>
<br>
I do not list the Status Quo as an option because it is terrible and has <br>
led us to regularly have complaints from both GHC & Ecosystem libraries <br>
maintainers. There can be no half-measures that they usually tend to <br>
make us slide back into the status quo.<br>
<br>
So, what do you think?<br>
<br>
<br>
¹ <br>
<a href="https://gitlab.haskell.org/ghc/ghc/-/issues/?label_name%5B%5D=Safe%20Haskell" rel="noreferrer noreferrer noreferrer" target="_blank">https://gitlab.haskell.org/ghc/ghc/-/issues/?label_name%5B%5D=Safe%20Haskell</a><br>
<br>
² <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/19605" rel="noreferrer noreferrer noreferrer" target="_blank">https://gitlab.haskell.org/ghc/ghc/-/issues/19605</a><br>
<br>
³ <a href="https://github.com/haskell/directory/issues/147" rel="noreferrer noreferrer noreferrer" target="_blank">https://github.com/haskell/directory/issues/147</a><br>
<br>
<br>
-- <br>
Hécate ✨<br>
🐦: @TechnoEmpress<br>
IRC: Hecate<br>
WWW: <a href="https://glitchbra.in" rel="noreferrer noreferrer noreferrer" target="_blank">https://glitchbra.in</a><br>
RUN: BSD<br>
<br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" rel="noreferrer noreferrer" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div>