-
Notifications
You must be signed in to change notification settings - Fork 37
[Merged by Bors] - Fixed a bug in replace returns #352
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>
|
bors try |
|
Could we just use julia> f(expr) = :(return ($expr, 1.0))
f (generic function with 1 method)
julia> f(:(x = 10))
:(return (x = 10, 1.0))
julia> @eval f(:(x = 10))
:(return (x = 10, 1.0))
julia> @eval $(f(:(x = 10)))
ERROR: syntax: invalid named tuple element "1"
...
julia> f(expr) = :(return (begin $expr end, 1.0))
f (generic function with 1 method)
julia> f(:(x = 10))
:(return (begin
#= REPL[11]:1 =#
x = 10
end, 1.0))
julia> @eval $(f(:(x = 10)))
(10, 1.0)
julia> x
10 |
That's a good idea! Is this preferable to a temporary variable? It looks less intuitive to me, though I agree it's nice to not have the intermediate variable. I'm fine with either way though, so if you prefer |
|
Btw, Turing tests are passing on both Julia 1.3 and 1.6 locally with this. So once we've made the decision above, we'll be ready for a proper release. |
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.
Both approaches look good to me - the intermediate variable looks a bit more intuitive!
|
I think the |
I don't think perf is much of a concern here tbh, since this particular usage will be hit at most a couple of times for a given model (and in particular not compared to the heavy usage of |
|
bors r+ |
On master we have the following behavior for a test-case in Turing.jl: ```julia julia> @macroexpand @model empty_model() = begin x = 1; end quote function empty_model(__model__::DynamicPPL.Model, __varinfo__::DynamicPPL.AbstractVarInfo, __context__::DynamicPPL.AbstractContext; ) #= REPL[5]:1 =# begin #= REPL[5]:1 =# #= REPL[5]:1 =# return (x = 1, __varinfo__) end end begin $(Expr(:meta, :doc)) function empty_model(; ) #= REPL[5]:1 =# return (DynamicPPL.Model)(:empty_model, empty_model, NamedTuple(), NamedTuple()) end end end ``` Notice the `return` statement: it converted the statement `x = 1` which returns `1` into an attempt at a `NamedTuple{(:x, :__varinfo__)}`. On Julia 1.6 we don't really notice much of difference, because `first` and `last` will have the same behavior, but on Julia 1.3 the tests would fail in TuringLang/Turing.jl#1726 since "implicit" names in construction of `NamedTuple` isn't supported. This PR addresses this issue by simply capturing the return-value in separate variable, which is then combined with `__varinfo__` in a `Tuple` at the end. This should both fail and succeed whenever standard Julia code would.
|
Pull request successfully merged into master. Build succeeded: |
On master we have the following behavior for a test-case in Turing.jl:
Notice the
returnstatement: it converted the statementx = 1which returns1into an attempt at aNamedTuple{(:x, :__varinfo__)}. On Julia 1.6 we don't really notice much of difference, becausefirstandlastwill have the same behavior, but on Julia 1.3 the tests would fail in TuringLang/Turing.jl#1726 since "implicit" names in construction ofNamedTupleisn't supported.This PR addresses this issue by simply capturing the return-value in separate variable, which is then combined with
__varinfo__in aTupleat the end. This should both fail and succeed whenever standard Julia code would.