Jaro

Here's a simple standalone program that produces the same kind of error message: ```haskell {-# LANGUAGE RankNTypes #-} f :: (forall a. a -> String) -> String f g =...

> Does GHC not already do this? Maybe the result is different with -wall? GHC doesn't show any error or warning, even with `-Wall` or `-Weverything`. But even if it...

I've converted `IntSet` and `IntMap` to `Word64Set` and `Word64Map` as part of this GHC MR: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10568 It would require some polishing before upstreaming it. I might have time for it...

That depends on what you consider to be too much. The simplest way to upstream these is to just copy the files, but I get the impression you consider adding...

@Bodigrim suggested we use CPP following other boot libraries like `filepath`. That seems like a promising approach. Concretely `filepath` defines [System.OsPath](https://github.com/haskell/filepath/blob/master/System/OsPath.hs) like this: ```haskell {-# LANGUAGE CPP #-} #define FILEPATH_NAME...

Yes, that seems like a disadvantage, e.g. this link doesn't point to anything useful: https://hackage.haskell.org/package/filepath-1.4.100.3/docs/src/System.OsPath.Posix.html#extSeparator

I have a better solution, we can rewrite `Ctl` into a monad transformer `CtlM` which can run `IO` actions properly. Then you only need one `unsafePerformIO` at the top level...

If I compile with optimizations then I can still reproduce it.

@xnning I think this pull request is a bit outdated. Wrapping `Ctl` with `IO` like I do in #7 is in my opinion a much better and probably much more...

I have been able to implement it like this: ```Haskell data ContextT e e' where CTCons :: !(Marker ans) -> !(h e' ans) -> !(ContextT e e') -> ContextT e...