Ohad Kammar

Nice! Since this implementation is computing things differently, not just faster, we should at least try to check that it's producing the correct results, not just producing results faster.

We should understand what the proposed change is doing a bit more before merging. I wrote it in issue #245, but it also belongs here. The [paper](https://arxiv.org/pdf/1711.03219.pdf) and its [follow-up](https://dl.acm.org/doi/10.1145/3236778)...

@reubenharry 's [reply](https://github.com/tweag/monad-bayes/issues/245#issuecomment-1385941236) is correct: monad-bayes only assumes (and provides) a monad structure, and the monad laws don't hold for the resulting structure. Shipping our own copy of `ListT` will...

> Well, as a Haskell developer, I will always assume that of course anything that has a `Monad` instance is lawful. A library that sweeps that under the rug without...

I'm not sure how the qualified do-notation helps here when what we're using is the existing monad-structure transformer ecosystem that postulates a Monad interface.

Is it correct though?

Thanks for the detailed explanation. First, can we please correct some imprecise assertions in it? > I'm not even sure how one can argue that the old version was correct,...

Thanks for implementing additional tests! (Something is currently failing in the build, though.) > I'm not saying that `FreeT m []` a represents a population, but I'm saying that if...

Yes, I wonder whether these should be indexed in reverse (a node in the tree has an env. variable associated with it, and it's shared with its subcommands).

This would work well with a more expressive library of parsers.