Open yebai opened 1 week ago
There's a big discussion that seems very relevant here: #589
But the syntax you propose is not possible to achieve. It would have to be a macro, unless we want to start messing with function calls in a model, which really doesn't seem like something we want to do :confused:
But the syntax you propose is not possible to achieve. It would have to be a macro, unless we want to start messing with function calls in a model, which really doesn't seem like something we want to do 😕
I am aware of this. It is easily approachable by replacing all returned_quantities
calls with @returned_quantities
as part of the @model
transformation if we want. I don't think the issue is the difficulty of implementation, but rather, it is if we wish to abuse the function call syntax slightly. I can see the arguments for preferring not to go down that route; if so, we can use @returned_quantities
instead of returned_quantities
in the above example.
Currently implemented operations on Turing models:
Proposed new model operation
returned_quantities
This will replace and unify two current syntax
submodel
andgenerated_quantities
. A reviewer for a Turing.jl preprint has pointed out that thegenerated_quantities
is confusing due to the name clash with Stan's generated quantities block, but with different motivations (Stan's generated quantities are entirely motivated for performance while ours is a return statement that can be used for many purposes).Another consideration is that
submodel
andgenerated_quantities
have almost identical semantics from the user's perspective: both syntaxes obtain the returned variables of a model. However, thesubmodel
syntax requires some special treatment for inference purposes, i.e., storing allsubmodel
random variables in the parent model'sVarInfo
. This distinction doesn't matter much for users and won't deserve two separate syntaxes.In addition, the
generated_quantites
becomes