-
Notifications
You must be signed in to change notification settings - Fork 31
Hacky way of supporting AdvancedPS.jl #483
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
And not very unexpectedly, this breaks models involving |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm certainly not a fan of @generated
if it can be avoided, due to its limitations and impact on compilation times. Due to all the disadvantages you mentioned I'd really like to not merge this PR. Also partially fixing SMC with kwargs while breaking other use cases doesn't seem convincing.
Since the supported model classes for SMC will be limited even with this PR, maybe it's fine to just not support kwargs with SMC and PG until it is fixed upstream? We should just make sure that it's not silently broken - could we add a check in DynamicPPL that throws a descriptive error if kwargs are used with SMC or PG (I guess this might need a trait for LibTask-samplers)?
Oh I'm also very much with you that this is not a great way to go about things. I put it here as a "this is a last resort bandaid but it's hacky as hell" (didn't put it in draft mode because I wanted to run tests).
I'm honestly fine with this. We can also do it in an easier way: in the construction of the taped task we just check if |
Also sounds sensible to me! It's a good idea to keep the compiler as simple as possible. |
As discussed, we'd like to fix this from |
In #477 we introduced proper support for keyword arguments in the models.
As it turns out, this completely breaks integration with AdvancedPS.jl: TuringLang/Turing.jl#2001 and TuringLang/Libtask.jl#163.
But there is a way we can both support kwargs as in #477 and simultaneously preserving the current behavior of AdvancedPS.jl (though, as mentioned in the PR above, this still silently doesn't work for
@submodel
).The idea is to transform the evaluator (not the constructor) from
into the
@generated
This is similar to how
Base.kwcall
but with the difference that:(2) shouldn't really be a problem because we perform all of this in the constructor; the evaluator should never be called explicitly anyways.
The result is as follows:
But oh boy the expression is not looking fun:
Yeaaaah.
And it most certainly complicates the compiler.
All in all, I'm not entirely certain if this is the way to go. The problem is just that
kwargs...
, which can be quite annoying.In conclusion, I don't see a nice solution other than the above 😕
EDIT: There's also the "fun" effect that you can now also use
kwargs
to condition 🙃