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

Revision en1, by kadoban, 2017-06-29 10:09:46

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.

Tags haskell, ghc, safe haskell, array

History

 
 
 
 
Revisions
 
 
  Rev. Lang. By When Δ Comment
en2 English kadoban 2017-06-29 10:11:29 14 fixed capitalizations
en1 English kadoban 2017-06-29 10:09:46 2934 Initial revision (published)