I would be very careful with this request and possibly cherry pick, but following http://neilmitchell.blogspot.com/2015/09/detecting-space-leaks.html I was able to pinpoint several locations where stack overflows occurred. Mainly seemed to be due to lazy fmap (as noted in Data.IntMap.Strict documentation, some foldls instead of foldl's, and the like. There is definitely some redundancy with the bang patterns, so many may be extra (but did not result in any issues that I saw).
I also included the previous pull requests, so I'll delete those.
There's also a new function unsafeMkSp as IntM is not exposed, but for using libraries such as Control.Foldl I needed to somehow convert the raw IntMap (IntMap a) to be used.
Right now I'm unable to find additional locations, however, as I get stuck at liftI2 as a stack overflow but containers maintains that there is no issue with intersectionWith, so I don't know where else to look.
I would be very careful with this request and possibly cherry pick, but following http://neilmitchell.blogspot.com/2015/09/detecting-space-leaks.html I was able to pinpoint several locations where stack overflows occurred. Mainly seemed to be due to lazy
fmap
(as noted inData.IntMap.Strict
documentation, somefoldl
s instead offoldl'
s, and the like. There is definitely some redundancy with the bang patterns, so many may be extra (but did not result in any issues that I saw).I also included the previous pull requests, so I'll delete those.
There's also a new function
unsafeMkSp
asIntM
is not exposed, but for using libraries such asControl.Foldl
I needed to somehow convert the rawIntMap (IntMap a)
to be used.Right now I'm unable to find additional locations, however, as I get stuck at
liftI2
as a stack overflow butcontainers
maintains that there is no issue withintersectionWith
, so I don't know where else to look.