Poutine stack behavior

[eb8680]

Right now the entire poutine stack is applied at every Pyro primitive site, at least until a block is reached. Although the transparent flag takes care of many use cases we care about, it might be better if each poutine in the stack has to call the next one itself, so that otherwise they are never called at all. In the case where there are two or more non-transparent poutines in the stack, it seems wasteful to draw a sample from one and then immediately discard it at another (and potentially incorrect, if e.g. the stochastic function at the site produces exchangeable not but i.i.d. samples).

To this end, @ngoodman suggested the following changes:

we make available next_pyro_sample(), etc, functions that call the next lower poutine method. if it doesn't get called then lower poutine layers simply don't run; the return value is the prev_val (which no longer needs to be an explicit arg to sample, etc).

instead of having a transparent flag, the default behavior of the base poutine class would be to be transparent. we would provide a poutine.forward that provides the standard non-transparent methods.

The purpose of this issue is to discuss the details of potential changes to the poutine stack. See also #51 .

[eb8680]

For posterity/discussion: our poutine abstraction is very related to algebraic effect handlers, and making this connection more directly may help us really nail the design - see this library code and paper

[null-a]

our poutine abstraction is very related to algebraic effect handlers

Indeed! FWIW, the implementation in that paper is based on free monads, which is something I explored for a PPL over here. (Inspired in part by Practical Probabilistic Programming with Monads.) However, one significant difference is that what I have at present is closed, in the sense used in the paper you link, rather than open like pyro. Let me know if I can help out.

[eb8680]

Closed (for now) by #62