Renaming decondition to uncondition

README.md

@@ -50,7 +50,7 @@ Therefore, the interface consists of an `AbstractProbabilisticProgram` supertype
 functions
 
   - `condition(::Model, ::Trace) -> ConditionedModel`
-  - `decondition(::ConditionedModel) -> GenerativeModel`
+  - `uncondition(::ConditionedModel) -> GenerativeModel`
   - `sample(::Model, ::Sampler = Exact(), [Int])` (from `AbstractMCMC.sample`)
   - `logdensityof(::Model, ::Trace)` and `densityof(::Model, ::Trace)` (from
     [DensityInterface.jl](https://github.com/JuliaMath/DensityInterface.jl))
@@ -133,26 +133,26 @@ end
 m = foo(; Y=…, μ=…)::SomeConditionedModel
 ```
 
-From this we can, if supported, go back to the generative form via `decondition`, and back via
+From this we can, if supported, go back to the generative form via `uncondition`, and back via
 `condition`:
 
 ```julia
-decondition(m) == g::SomeGenerativeModel
+uncondition(m) == g::SomeGenerativeModel
 m == condition(g, @T(Y = …))
 ```
 
 (with equality in distribution).
 
 In the case of Turing.jl, the object `m` would at the same time contain the information about the
-generative and posterior distribution `condition` and `decondition` can simply return different
+generative and posterior distribution `condition` and `uncondition` can simply return different
 kinds of “tagged” model types which put the model specification into a certain context.
 
 Soss.jl pretty much already works like the examples above, with one model object being either a
 `JointModel` or a `ConditionedModel`, and the `|` syntax just being sugar for the latter.
 
 A hypothetical `DensityModel`, or something like the types from LogDensityProblems.jl, would be a
 case for a model type that does not support the structural operations `condition` and
-`decondition`.
+`uncondition`.
 
 The invariances between these operations should follow normal rules of probability theory.  Not all
 methods or directions need to be supported for every modelling language; in this case, a

docs/src/api.md

@@ -28,7 +28,7 @@ string_to_varname
 ```@docs
 AbstractProbabilisticProgram
 condition
-decondition
+uncondition
 fix
 unfix
 logdensityof

src/AbstractPPL.jl

@@ -18,7 +18,7 @@ export VarName,
 
 # Abstract model functions
 export AbstractProbabilisticProgram,
-    condition, decondition, fix, unfix, logdensityof, densityof, AbstractContext, evaluate!!
+    condition, uncondition, fix, unfix, logdensityof, densityof, AbstractContext, evaluate!!
 
 # Abstract traces
 export AbstractModelTrace

src/abstractprobprog.jl

@@ -20,26 +20,26 @@ in `model`, at specific values for the random variables given through `trace`.
 
 `trace` can be of any supported internal trace type, or a fixed probability expression.
 
-`logdensityof` should interact with conditioning and deconditioning in the way required by
+`logdensityof` should interact with conditioning and unconditioning in the way required by
 probability theory.
 """
 DensityInterface.logdensityof(::AbstractProbabilisticProgram, ::AbstractModelTrace)
 
 """
-    decondition(conditioned_model)
+    uncondition(conditioned_model)
 
 Remove the conditioning (i.e., observation data) from `conditioned_model`, turning it into a
 generative model over prior and observed variables.
 
 The invariant 
 
 ```
-m == condition(decondition(m), obs)
+m == condition(uncondition(m), obs)
 ```
 
 should hold for models `m` with conditioned variables `obs`.
 """
-function decondition end
+function uncondition end
 
 """
     condition(model, observations)
@@ -52,7 +52,7 @@ unnormalized) posterior distribution over them.
 The invariant 
 
 ```
-m = decondition(condition(m, obs))
+m = uncondition(condition(m, obs))
 ```
 
 should hold for generative models `m` and arbitrary `obs`.