This issue tracks design choices about the relationship between ReparamMessenger and other messengers that set msg["value"] such as InitMessenger, ConditionMessenger, and ReplayMessenger.

The problem is that poutine.reparam is usually applied directly to a model, often inside the model at a specific site, whereas the value-setting effect handlers are usually applied as part of inference or prediction, after or outside of poutine.reparam. As a result, the model has already been rewritten by the time a value-modifying handler sees its target sample site. This situation would be fine in a fully general lightweight effect handler system where handlers could arbitrarily modify the effects of other handlers, but Pyro's effect handlers are organized around the simplifying concept of a handler stack, limiting effects to a small safe set of application orders. Thus solutions to this issue will need to work around the stack, e.g. by adding additional global handler state, directly inspecting the stack, or applying messengers out-of-stack-order.

Tasks

• Make ReparamMessenger aware of InitMessenger, simplifying initialization #2876 Make ReparamMessenger compatible with InitMessenger, for AutoGuides and MCMC (higher priority)
• Support init_to_value in NeuTraReparam
• Support init_to_value in StructuredReparam
• Make ReparamMessenger compatible with ConditionMessenger for posterior predictive sampling (lower priority)