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