Significantly simplify the tilde-pipeline in DynamicPPL

[mhauru]

TODO

Edit this issue with more details about what needs to be done

Related issues

• Confusion regarding .~ DynamicPPL.jl#722
• evaluate!! shenanigans DynamicPPL.jl#720
• Simplify assume/observe design DynamicPPL.jl#402

[yebai]

As briefly discussed with @mhauru, we could introduce a new (internal) macro DynamicPPL.@get_paramter_type(x::VarName) to replace the current hard-coded logic for determining whether a parameter is missing, observation, fixed or random variable. This is related to @isobservation in TuringLang/DynamicPPL.jl#714 (I don't think we need @observed_value(x) since this is available in the model scope).

[torfjelde]

don't think we need @observed_value(x) since this is available in the model scope

Maybe I misunderstand, but this is not available in the model scope in the case where x is conditioned using condition, right? That's the problem the @value in the issue is meant to address. Ofc, technically you could get it from the __context__, but you need to call the right function on this context, etc. which seems overly complicated for the end-user, no?

[torfjelde]

(internal) macro DynamicPPL.@get_paramter_type(x::VarName) to replace the current hard-coded logic for determining whether a parameter is missing, observation, fixed or random variable.

So, currently, the generation of these branches is done by separate functions, e.g. generate_tilde_assume or something in DynamicPPL.jl, right? Do you want to replace these functions that act on Expr with macros that are embedded in the model? If so, isn't that just doing the same thing?

I'm probably not understanding correctly here 🤔

[yebai]

his is not available in the model scope in the case where x is conditioned using condition, right? That's the problem the @value in the issue is meant to address. Ofc, technically you could get it from the context, but you need to call the right function on this context, etc. which seems overly complicated for the end-user, no?

Not sure what is the exact behaviour of left ~ distr if left is a conditioned variable. If it is not yet exposed to the model scope, we should modify the tilde pipeline to ensure that conditioned variables are exposed, e.g.,

# final step of tilde pipeline
left = conditioned_value

This would ensure that conditioned variables are accessible in the model scope (s.t. local scope constraints).

So, currently, the generation of these branches is done by separate functions, e.g. generate_tilde_assume or something in DynamicPPL.jl, right? Do you want to replace these functions that act on Expr with macros that are embedded in the model? If so, isn't that just doing the same thing?

This is not about adding new functionality. The purpose is to refactor the code and consolidate it into a single macro/function that we can use internally but exported as a public API.