We currently use chirho.interventional.handlers.do and chirho.observational.handlers.condition in most user-facing code and documentation because they are drop-in replacements for pyro.do and pyro.condition respectively.
However, using do and condition in library code leads to some internal inconsistencies in API design and semantics that will be annoying to work around in the future. This issue tracks work on switching to using more idiomatic and consistently specified query handlers internally.
Tasks:
We currently use
chirho.interventional.handlers.doandchirho.observational.handlers.conditionin most user-facing code and documentation because they are drop-in replacements forpyro.doandpyro.conditionrespectively.However, using
doandconditionin library code leads to some internal inconsistencies in API design and semantics that will be annoying to work around in the future. This issue tracks work on switching to using more idiomatic and consistently specified query handlers internally.Tasks:
ConditionMessengertoObservationsRename DoMessenger and ConditionMessenger query handlers #389InterveneMessengertoInterventionsRename DoMessenger and ConditionMessenger query handlers #389Splitshandler tochirho.counterfactual.handlersthat insertssplitoperations directly Add Splits handler #390dowithInterventions(orSplitswhereSplitsis correct and more precise)conditionwithObservations