Re: [Haskell-cafe] Safe Haskell?

Hrmm “ - RULES — Rewrite rules defined in a module M compiled with Safe https://downloads.haskell.org/ghc/latest/docs/html/users_guide/exts/safe_has... are dropped. Rules defined in Trustworthy modules that M imports are still valid and will fire as usual. ” Huh I suppose I’m wrong! I thought it was difference or more subtle than that On Tue, May 4, 2021 at 2:38 PM Carter Schonwald wrote:

Are you sure?

It also says "The use of Safe to compile Danger restricts the features of Haskell that can be used to a safe subset. This includes disallowing unsafePerformIO, Template Haskell, pure FFI functions, RULES and restricting the operation of Overlapping Instances."

On Tue, May 4, 2021 at 8:32 AM Oleg Grenrus wrote:

...

The GHC manual says [1]

RULES — Rewrite rules defined in a module M compiled with Safe are dropped. Rules defined in Trustworthy modules that M imports are still valid and will fire as usual.

So rules are still in use, and e.g. list fusion works. Library authors cannot define their own RULES in Safe modules, but they are (always, no need to -Wall) warned about the fact that these rules are ignored. I don't see a possibility for silent performance regressions.

- Oleg

[1]:

https://downloads.haskell.org/ghc/9.0.1/docs/html/users_guide/exts/safe_hask...

On 4.5.2021 15.10, Carter Schonwald wrote:

...

Default safety isn’t quite what you want in normal packages, because that disables all user land rewrite rules! It may have other implications too, but short of augmenting ghc with a proof system for correctness of rewrite rules, default safehaskell is at odds with optimized builds.

On Mon, May 3, 2021 at 10:28 AM Richard Eisenberg mailto:rae@richarde.dev> wrote:

...

On May 3, 2021, at 7:40 AM, Tom Smeding mailto:x@tomsmeding.com> wrote:

But perhaps I'm being ignorant of other existing cases where this already matters, and I've been living in an idealised world until now.

Sad to say it, but order does matter here.

In the very simple case, if you have {-# LANGUAGE FlexibleContexts, NoFlexibleContexts #-}, that's different from {-# LANGUAGE NoFlexibleContexts, FlexibleContexts #-} -- later extensions override earlier ones. This problem becomes more confounding when we recognize that some extensions imply others. For example {-# LANGUAGE TypeFamilies, NoMonoLocalBinds #-} means something different from {-# LANGUAGE NoMonoLocalBinds, TypeFamilies #-} because TypeFamilies implies MonoLocalBinds. Perhaps even worse, {-# LANGUAGE CUSKs, StandaloneKindSignatures #-} differs from {-# LANGUAGE StandaloneKindSignatures, CUSKs #-} because StandaloneKindSignatures implies NoCUSKs.

Returning to Safe Haskell:

It's true that Safe cannot be overridden locally. This is implemented by the fact that NoSafe does not exist. To me, this design makes sense, because it means that compiling with `ghc -XSafe` is guaranteed to use Safe Haskell. So we would need something like a default-safety field in Cabal, that could be overridden locally.

But, still, this may be easier than the status quo.

Do we think this would work? Specifically:

* Introduce a new flag -fdefault-safety={safe,trustworthy,unsafe} that changes the module-level default. This default names the safety level in effect for any module that declares none of Safe, Trustworthy, or Unsafe. * If -fdefault-safety is not specified at the command line, it is as if the user wrote -fdefault-safety=unsafe.

And that's it.

Consequence: Safe-inference would never take place, because every module would have a declared level of Safety. The Safe-inference code could thus be removed.

Further work: Introduce default-safety in Cabal, but that's not really necessary to make the changes above.

What do we think?

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.

_______________________________________________ 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.

---

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.