[Haskell-cafe] Safe Haskell?
cdsmith at gmail.com
Fri Apr 16 19:31:20 UTC 2021
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
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.
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe