[Haskell-cafe] Safe Haskell?

[Oleg Grenrus]

I don't think adding {-# LANGUAGE Safe #-} (as we do with -Wall) is a
good idea.

The culprit is Safe-inference. While authors of the original Safe
Haskell paper
argue that it makes more modules Safe without package maintainer knowing
about Safe Haskell, problems on Hackage have shown that it is not the
case.

We simply cannot rely on Safe-inferred modules (continue) being Safe
when new
versions are released, or worse, when their transitive dependencies change.
There are various examples, I had made such mistakes ([1] is most recent
one).
([5] is an example of "dependency" change, luckily caught by explicit
pragmas).

I have implemented -Winferred-safe-imports [2] to warn about such
cases.  And
also -Wmissing-safe-haskell-mode [3], and used them successfully to cleanup
some Safe Haskell mess in Edward Kmett's packages [4].  (If you rely on
older
versions of the listed packages to be Safe: don't, you are asking for
troubles).

Another alternative, which IIRC Edward used previously, is to just stamp {-#
LANGUAGE Trustworthy #-} everywhere.  But that undermines the whole idea
in my
opinion. It's almost as bad as saying nothing, every Trustworthy module
have to be audited.

Yet, you have to use Trustworthy if your package uses Data.Coerce or
depends on
vector-package or... So while I and others put many hours into making
more of
ecosystem Safe Haskell, I feel it is work with very bad ROI.  (I
wouldn't have
done scan like [4] if there weren't also another reason to do it).

So while people may freely discuss whether Safe-Haskell or sandboxes are
better
setup for running untrusted code, Safe Haskell have been around for almost a
decade.  If lambdabot is really the only application people can publicly
talk
about, I just don't feel it's good enough motivation to keep the language
feature and add extra burden for the package maintainers. It is one more
thing
to know about, as if Haskell package authoring and  maintenance weren't
complicated enough already. As I mentioned, Safe-inferred just doesn't
work in
practice, so package maintainers have to be aware of it.  (Compare to
the good
practice of having type signatures for top-level bindings, Safety is a
part of
module signature).

TL;DR Safe Haskell requires buy-in from every maintainer, but there are
barely
any users. For how much longer we need to run this "academic experiment"?

- Oleg

[1]: https://github.com/ekmett/free/pull/204
[2]:
https://downloads.haskell.org/ghc/latest/docs/html/users_guide/exts/safe_haskell.html#ghc-flag--Winferred-safe-imports
[3]:
https://downloads.haskell.org/ghc/latest/docs/html/users_guide/exts/safe_haskell.html#ghc-flag--Wmissing-safe-haskell-mode
[4]: https://github.com/ekmett/lens/issues/959
[5]: https://github.com/haskell/time/compare/1.11.1...1.11.1.1

On 28.4.2021 17.16, Ignat Insarov wrote:
> Maybe the problem is really that Safe Haskell is not taken to be a
> default good practice?
>
> For example, it is easy to know that I should be setting `-Wall`, but
> hard to know that I should also enable some other warnings not
> included in `-Wall`. I know the latter because I read some blog posts
> somewhere and figured there is a consensus that these additional
> warnings are good, so I enable them by default.
>
> For Safe Haskell, I have not read any such blog posts and I have no
> idea whether it is a good practice to enable it. This feature is not
> discoverable. This may be a marketing problem.
>
> I have a template for my Haskell projects that enables a bunch of
> extra warnings, language extensions that I like to have enabled by
> default, dependencies that I wish were in `base`, and so on. Should
> Safe Haskell go into that template?
> _______________________________________________
> 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.