<div dir="auto">There's really only one situation where I've personally felt I needed something like Safe Haskell—and Safe Haskell doesn't deliver it. Specifically, it's very hard to know whether it's safe to use a particular class method at a particular type.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Apr 16, 2021, 3:03 PM Richard Eisenberg <<a href="mailto:rae@richarde.dev" target="_blank" rel="noreferrer">rae@richarde.dev</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">Hi café,<div><br></div><div>Do you use Safe Haskell? Do you know someone who does? If you do, which of Safe Haskell's guarantees do you rely on?</div><div><br></div><div>Here, a user of Safe Haskell is someone who relies on any guarantees that Safe Haskell provides, not someone who makes sure to have the right pragmas, etc., in your library so that users can import it Safely.</div><div><br></div><div>Context: Safe Haskell is not lightweight to support within GHC and the ecosystem. Despite being a formidable research project with a (in my opinion) quite worthwhile goal, it's unclear which of Safe Haskell's purported guarantees are actually guaranteed by GHC. (The lack of unsafeCoerce is not actually guaranteed: <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/9562" rel="noreferrer noreferrer" target="_blank">https://gitlab.haskell.org/ghc/ghc/-/issues/9562</a>.) Recent design questions about what should be Safe and what shouldn't be (somehow cannot find the discussion after a few minutes of searching; perhaps fill this in) have been answered only by stabs in the dark. The status quo is causing pain: <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/19590" rel="noreferrer noreferrer" target="_blank">https://gitlab.haskell.org/ghc/ghc/-/issues/19590</a>. There are hundreds (maybe thousands) of lines of delicate logic within GHC to support Safe Haskell. These parts of GHC have to be read, understood, and maintained by people with limited time.</div><div><br></div><div>I thus wonder about deprecating and eventually removing Safe Haskell. I don't have a concrete plan for how to do this yet, but I'm confident we could come up with a migration strategy.</div><div><br></div><div>The set of people who would win by removing Safe Haskell is easy enough to discover. But this email is intended to discover who would be harmed by doing so. If you know, speak up. Otherwise, I expect I will write up a GHC proposal to remove the feature.</div><div><br></div><div>Thanks,</div><div>Richard</div></div>_______________________________________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
Only members subscribed via the mailman list are allowed to post.</blockquote></div>