<div dir="ltr">I do not object!<div><br></div><div>I did use SafeHaskell long ago, to provide a server that executed student code in a class.  It lasted for a year or so, and caused me great anxiety because I was never entirely sure that it was really safe.  At a minimum, it required a bunch of extra logic at build time, careful monitoring of resource usage, etc.  I now believe that this use case is far better served by virtualization, which is now a quite well-supported feature across all major operating systems.  It would be a big mistake for someone today to try to accomplish with SafeHaskell what is better accomplished with a virtual machine.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Apr 16, 2021 at 3:07 PM Richard Eisenberg <<a href="mailto:rae@richarde.dev">rae@richarde.dev</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"><div style="overflow-wrap: break-word;">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" 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" 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" 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>