Manuel Bärenz
Manuel Bärenz
> Is there a reason we can't using one of the existing `ListT` replacement libraries? They generally work differently than what we want here. They allow for an effect after...
With help of the Berlin Haskell Users Group, I figured out that I didn't understand the situation about why `ListT` isn't lawful completely. The issue is not so much that...
The best free list transformer for this is probably https://hackage.haskell.org/package/free-5.1.3/docs/Control-Monad-Trans-Free-Ap.html#t:FreeT, which makes use of the `Applicative` instance of lists. Together with `ApplicativeDo`, this should be more performant in usual use...
> and the monad laws don't hold for the resulting structure. Yes, they certainly don't. For reproduceability when debugging a sampler, or also a formal implementation like delayed sampling (https://github.com/tweag/monad-bayes/issues/224),...
I tried replacing the deprecated `ListT` by a free monad over the applicative list. In fact it speeds up the benchmarks significantly! See https://github.com/tweag/monad-bayes/pull/253 for details. So I think it's...
The issue of looking into `Vector` or other replacements for lists is a separate one.
Good question, I'm pretty sure that yes. ## Old `ListT` Let's look at how the deprecated `ListT m a` worked. It's isomorphic to `m [a]`, and `join :: m [(m...
My point is that `runPopulation $ (a >=> b) >=> c = runPopulation $ a >=> (b >=> c)` in the new implementation, but not in the old. Furthermore, `runPopulation...
Ah ok, I think I'm getting it now. Your last explanation helped me. Put yet differently, the way the other transformers push around the population can result in all sorts...