-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
RFC: better ntuple implementation without @generated
#13439
Conversation
end | ||
end | ||
if isdefined(Core, :Inference) && isdefined(Core.Inference, :add_tfunc) | ||
Core.Inference.add_tfunc(ntuple, 2, 2, _ntuple_tfunc) | ||
end |
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.
Does all this have to go here rather than in inference.jl
?
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.
yes, that's part of the strategy here. there are two ntuple
functions (Core.Inference and Base), and inference needs to know about both.
I love the idea of this, and |
+1 to replacing generated functions with simpler approaches. However we should not do this by manually adding t-functions; they are too hard to write and only improve type information and not necessarily the generated code. Discussed with @vtjnash and concluded that (in addition to |
Ref #414 |
I'm unconvinced that more than one purity annotation is necessary – one that tells the compiler that the function can be evaluated at any time, including not at all if only the result type is needed and it can be determined without evaluation. It's probably fine for that function to actually have side effects since that makes it easy to do things like print inside of the function to see when the compiler actually decided to call it. |
I believe in m you conversation with Jeff we noted that the compiler may detect various addition properties (such as a function the operates only on the type domain) and use that to supplement the user annotation. |
Ref #13555 |
Yes probably just |
sufficient for what? |
Sufficient for type domain functions. |
instead of requiring
Val
to force constant propagation through dispatch, this allows type-inference to directly reason about the higher-level functionality ofntuple
.this is an example of one mechanism that could be used for avoiding needing a
@generated
function (and, as a bonus, a usage ofVal
in this case). this is not to pick on ntuple (added by @timholy in ae0ce5f), but to open a larger discussion about having more efficient code generation and runtime behaviors though more direct coupling.ping @JeffBezanson @carnaval who I think might already have ideas for evolving this