-
Notifications
You must be signed in to change notification settings - Fork 22
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
Using @generated less? #21
Comments
I think we should investigate the following claims before we make a decision on recursion vs generated.
|
A mechanism to hook into with Parameters.jl to avoid both generated and recursion-hoops would certainly be good. |
@mauro3 Actually, I was wrong to present it like @jw3126 These are good points, and interesting ones. I just had a vague impression that Julia core devs generally discourage
I guess for generating code, |
There is also
I have no practical experience with |
See #22 for some investigations on these claims. |
I also opened a question on discourse https://discourse.julialang.org/t/why-not-use-generated/29531 |
Most of my packages use recursion everywhere. Especially DimensionalData.jl and DynamicGrids.jl. I think the key heuristic is to use recursion when I understand exactly what is happening inside a function call and know it will compile away, and to use generated if not. With the pull request my instinct would be that setproperties is too complicated to compile away as well as the generated version, especially the do block. The compiler seems to back away from resolving constant propagation to decide if else blocks at some point. It might work if dispatch was used for everything. |
@rafaqz Are you talking about the restriction that the generator body has to be pure? But I guess it is not an issue here since we don't call API functions insde As @jw3126's analysis #22 (comment) shows that there is no benefit for going Having said that, another hybrid approach may be to define a function function setproperties(obj, patch::NamedTuple) =
...some argument checking...
return constructorof(typeof(obj))(Tuple(merge(asnamedtuple(obj), patch))...)
end This only invokes generated function for different types of |
I like the |
FYI some discussion of |
I don't see a justification for using `@generated`. The effects are good without it: ```julia-repl julia> Base.infer_effects(constructorof, Tuple{Type{Int}}) (+c,+e,+n,+t,+s,+m,+u,+o,+r) ``` Updates JuliaObjects#21
We are relying on
@generated
and it may create some concerns when using this package (e.g., mauro3/Parameters.jl#50).I think the biggest issue is that
setproperties
generates a function for different patch type (e.g., different combination or even ordering of the property names).It would be nice to write
setproperties
based on constant-propagatable code (e.g., recursions) and avoid using@generated
. However, the major obstacle is thatfieldnames
cannot be inferred. To workaround this, how about just use? We already use
fieldnames
inside@generated
so this is not worse than the current situation.Packages that controls
struct
definition like Parameters.jl can even define__fieldnames__
andconstructorof
to completely avoid@generated
.The text was updated successfully, but these errors were encountered: