Jan Stolarek

It looks like match flattening was the cause of huge memory usage during compilation of `Data.Singletons.Prelude.List` module. See #96.

It also seems that there might have been a bug in the implementation of match flattening, which caused failure of Singletons/Nat test. See #97.

> Do let me know if you're taking this on! :) Not in the next weeks - I'm totally swamped with teaching and once this is over (in two weeks)...

I admit that this possibility crossed my mind when writing my comment :-)

Speaking of `even`, it is implemented in terms of `rem`. Do we plan to provide promoted/singletonized `Integral` type class?

Yes, this looks like GHC's fault. See [#8095](https://ghc.haskell.org/trac/ghc/ticket/8095). There are many related tickets, e.g. [#12506](https://ghc.haskell.org/trac/ghc/ticket/12506), [#11598](https://ghc.haskell.org/trac/ghc/ticket/11598)

As expected, with `-O0` the module compiles in less than a few seconds and uses only 350MB of RAM. Still I wonder when this started happening.

Yes, I meant `Data.Singletons.Prelude.List`. > (This problem started when I moved a ton of functions from promotion-only to singletonizing, allowed now because of the work on #30.) My guess was...

I have just been bitten by this one again. This time - in conjunction with [#10228](http://ghc.haskell.org/trac/ghc/ticket/10228) - I was unable to compile `singletons` on one of my machines. Richard, your...

Optimisations matter but even without them the situation does not look too good. For now I extracted zips into a separate module and disabled optimisations - travis build no loner...