[Haskell-cafe] Safe Haskell?

[Chris Smith]

I do not object!

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.

On Fri, Apr 16, 2021 at 3:07 PM Richard Eisenberg <rae at richarde.dev> wrote:

> Hi café,
>
> Do you use Safe Haskell? Do you know someone who does? If you do, which of
> Safe Haskell's guarantees do you rely on?
>
> 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.
>
> 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:
> https://gitlab.haskell.org/ghc/ghc/-/issues/9562.) 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: https://gitlab.haskell.org/ghc/ghc/-/issues/19590. 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.
>
> 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.
>
> 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.
>
> Thanks,
> Richard
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210416/572221c8/attachment.html>