Codeforces's haskell setup is bad (with respect to "Safe Haskell")

#	User	Rating
1	tourist	4009
2	jiangly	3823
3	Benq	3738
4	Radewoosh	3633
5	jqdai0815	3620
6	orzdevinwang	3529
7	ecnerwala	3446
8	Um_nik	3396
9	ksun48	3390
10	gamegame	3386

#	User	Contrib.
1	cry	167
2	Um_nik	163
3	maomao90	162
3	atcoder_official	162
5	adamant	159
6	-is-this-fft-	158
7	awoo	157
8	TheScrasse	154
9	Dominater069	153
9	nor	153

The way codeforces is using GHC's "Safe Haskell" extension is disabling the use of very common and useful modules and extensions, for no benefit that I can figure out.

Importing any of these:

Control.Monad.ST
Data.Array.ST
Data.Array.MArray
Data.Array.IO
Data.Vector
Data.Vector.Unboxed

(and probably more, but these are the ones I tried) gives an error of the form:

    Control.Monad.ST: Can't be safely imported!
    The module itself isn't safe.

Additionally, the GeneralizedNewtypeDeriving (GND) and TemplateHaskell (TH) language extensions are disabled. (compiling with them turned on doesn't error, but they're ignored, so if you try to use them you then get errors).

All of these disabled things are very useful. As-is the haskell setup on codeforces has no performant mutable arrays available at all, which it's hard to overstate how wacky that is in competitive programming.

The GND extension is quite useful as well since it avoids having to tediously reimplement typeclasses when you wrap a type.

TH is haskell's metaprogramming facility, like templates in C++ or macros in C. It doesn't get used as much as those features do in their respective languages, but it's still handy now and then.

I'm not really sure why all of this is disabled or exactly what switches are being used to GHC, though it's obviously related to safe haskell.

To make it clear, the sense in which "safe haskell" is safe is not useful for codeforces. In the programs we write, we're allowed to do unrestricted IO (at the language level at least, I assume there's a VM wrapper or restrictions on I/O at the OS level) in the standard main entry point to haskell programs. And since we're not writing a library, this is just an executable and used for nothing else, it doesn't make sense to judge the safety of the API we're exporting. There is no safety, you're running the IO action that we specify anyway and that's the only interface.

I would be interested what the motivation is for turning on safe haskell, especially in this way that disallows the use of very common modules and data structures. Even if safe haskell is somehow required (maybe TH would be a risk at compile time the way CF is set up?), there are still ways to whitelist certain modules/packages so we could use them, and this would have no risk that I can imagine.

While I'm at it, the version of GHC allowed is getting pretty old too. Something in the 8.x family, or even 7.10.x would be nice; there have been a couple of nice language changes since 7.8.3. Also 7.8.3 is kind of a uniquely annoying version because one of the common ways to get GHC is via the 'stack' tool, which doesn't support that version. The oldest it knows about is GHC 7.8.4. This makes it a bit uncertain trying to develop and test code locally for CF use.