…and now that it’s been coughed regurgitated brought up yet again in the context of language editions:
Deprecating Safe Haskell
So what was the intended purpose of Safe Haskell?
So if it really is time for Safe Haskell and its ecosystem to be dismantled, such “loophole” language features (old and new) as well as their associated ecosystems should also be included in said dismantling to avoid regressing (in this case) all the way back to Haskell 2010:
Renovating Safe Haskell
Haskell is (meant to be) a declarative language. So a module written in ordinary, boring un-extended Haskell ought to be safe by default - there ought to be no need at all to explicitly label that module as being Safe
. Instead, any module which uses unsafe language features should be be labelled “unsafe” in some way.
Since unsafe
has already be reserved for a technical purpose in the FFI, and based on this post, a future Safe Haskell could use feign
as an annotation for both unsafe modules:
module feign MotleyBits (...) where
and their imports:
import feign MotleyBits (...)
Note:
-
there should be no way to “override” the absence of either annotation if Safe Haskell is enabled - if users don’t want to see the resulting warnings (or errors if need be) they must add the annotations.
-
there should be no transitivity - if module
A
imports from moduleB
, andB
imports from an unsafe moduleC
, then onlyB
requires the annotated (feign
) imports. -
If there was some way to “deem” the likes of
runIO
and the variousPerformIO
s as being foreign to Haskell, reusing the existing reserved wordforeign
could be an alternative to introducingfeign
.
So instead of everyone else having to label their modules as “safe”, the few who use unsafe Haskell features in the sources for their modules would need to label those modules or their imports accordingly. This places the focus on unsafe modules and how to have less (or none) of them.