(speculative) turn `model.f` parameters into ConditionContext

[penelopeysm]

Right now we have two ways of conditioning, one through model arguments and one through contexts. However, it's unclear what happens if someone tries to do it both ways.

@model function f(a=1.0)
    a ~ Normal()
    return a
end

m = f()
cm = m | (; a=2.0)

cm() # returns 1.0, i.e. conditioning is ignored, but this behaviour is undefined

The cheapest fix would be to warn or error when somebody tries to condition on a model argument. (We can do this because the argument names, and values, are stored in the Model object.)

A different fix would be to somehow unify the two ways together, so that for example when one declares f(2.0) it's really turned into f without an argument, but with a ConditionContext.

I actually think this would be good. I used to have some concerns about ConditionContext, but that was all fixed since we simplified .~ (#804), and now I think it's much better than the old argument-passing. But I don't immediately know from a technical standpoint how to do this. (I think we would have to do some macro magic to generate a new method for f without arguments, then forward the f-with-arguments method to the f-without-arguments method.) In this case, as long as we prevent conditioning twice on the same variable we would avoid the undefined behaviour..

@yebai points out that having static parameter declaration a la of would solve this, though of course we are unsure when that will be ready.

[yebai]

A different fix would be to somehow unify the two ways together, so that for example when one declares f(2.0) it's really turned into f without an argument, but with a ConditionContext.

I have thought about this previously. We can keep the same arguments for f, but if an argument is LHS of tilde, we ignore the input argument, and look for the same variable in the ConditionContext (this is put into the model object upon construction).

[penelopeysm]

Ah yes, that's potentially a N-line fix (N < 10) here:

DynamicPPL.jl/src/compiler.jl

Lines 67 to 73 in 968c879

	# 3. We are working with a `ConditionContext` _and_ it's in the model arguments,
	# i.e. we're trying to override the value. This is currently NOT supported.
	# TODO: Support by adding context to model, and use `model.args`
	# as the default conditioning. Then we no longer need to check `inargnames`
	# since it will all be handled by `contextual_isassumption`.
	if !($(DynamicPPL.inargnames)($vn, __model__)) ||
	$(DynamicPPL.inmissings)($vn, __model__)

Although we'd probably still want to add a warning for this as well.

[yebai]

Although we'd probably still want to add a warning for this as well.

If the semantics are identical, which we could try, there is no need for a warning.

[yebai]

Upon further thought, though it is a good idea to turn model.f parameters into a context, it might be surprising if the user can condition again on the same variables without explicit uncondition. I lean towards the idea that we can err if users try to condition on variables that are passed as input arguments to the model.

[penelopeysm]

Couldn't we turn the parameters into the context, and then make conditioning on a conditioned variable an error, i.e. the user would have to decondition first before conditioning again? (I don't have much of an opinion on which way is better, just thinking)

[yebai]

Couldn't we turn the parameters into the context, and then make conditioning on a conditioned variable an error, i.e. the user would have to decondition first before conditioning again? (I don't have much of an opinion on which way is better, just thinking)

yes, that is what I am suggesting above.

[penelopeysm]

Ah, okay, I see