Update `Writer` to the CPS version in `mtl-2.3.1`
diegodiv opened this issue · 4 comments
The Writer monad we use in WebsocketServer.hs might prove leaky. Following #101 (comment), we could switch to the CPS version.
However, this would require modifying a lot of versions for the dependencies, as well as using packages outside of Stackage: there is no Stackage package set that contains mtl-2.3 or after. We could otherwise pin very precise versions in extra-deps and remove the version constraints in package.yaml and only pin the GHC version in stack.yaml as a resolver.
I tried to play a bit with that, but as far as it's not in any Stackage set, it will call for extra-deps. So far, I ended up with what stack sees as a cycle, but actually is a version mismatch it can't solve.
I could get something working by flooding extra-deps and changing the relevant parts of the code that were breaking, but that's not a very nice solution.
Since mtl is a boot library, it might be fiddly to convince stack to use a newer one than the one shipped with the GHC used. This might have to be something that just can't be done for the time being
Well, I got it to compile. Just take a look at the unwieldy mess it creates: c4164c0.
From what I can tell, the CPS'd version of WriterT is actually identical to StateT (i.e. WriterT w m a ~ w -> m (a, w) vs. StateT s m a ~ s -> m (a, s)), it just exposes a smaller external interface.
Also, we would still need a better monoid, since [] with the way the mappends are associated runs into the typical quadratic run time issue with building lists.
To save ourselves the trouble with messing with dependencies, and fixing the list building in the same go, we can just use StateT and build the output list using modify' which strictly updates the state and : rather than mappend/++ (thereby building the list in reverse).
If the order of the list matters, we can always do a final reverse, keeping everything running in linear time.
Sounds like a plan. The order of the list shouldn't matter.