Skip to content
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

Closed
wants to merge 1 commit into from

Conversation

vtjnash
Copy link
Member

@vtjnash vtjnash commented Oct 3, 2015

instead of requiring Val to force constant propagation through dispatch, this allows type-inference to directly reason about the higher-level functionality of ntuple.

this is an example of one mechanism that could be used for avoiding needing a @generated function (and, as a bonus, a usage of Val 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

end
end
if isdefined(Core, :Inference) && isdefined(Core.Inference, :add_tfunc)
Core.Inference.add_tfunc(ntuple, 2, 2, _ntuple_tfunc)
end
Copy link
Member

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?

Copy link
Member Author

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.

@timholy
Copy link
Member

timholy commented Oct 3, 2015

I love the idea of this, and ntuple has needed some love for some time. My addition was basically a bandaid.

@JeffBezanson
Copy link
Member

+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 @inline) we should have @pure, plus something similar to @pure but indicating that the function only depends on argument types, making it very easy to evaluate at compile time. This would generalize the hacks currently in place for functions like typejoin.

@simonster
Copy link
Member

Ref #414

@StefanKarpinski
Copy link
Member

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.

@vtjnash
Copy link
Member Author

vtjnash commented Oct 7, 2015

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.

@StefanKarpinski
Copy link
Member

Ref #13555

@JeffBezanson
Copy link
Member

Yes probably just @pure is sufficient.

@vtjnash
Copy link
Member Author

vtjnash commented Oct 13, 2015

sufficient for what? ntuple isn't pure.

@JeffBezanson
Copy link
Member

Sufficient for type domain functions.

@vtjnash vtjnash closed this Feb 14, 2016
@DilumAluthge DilumAluthge deleted the jn/less-at-generated branch March 25, 2021 22:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants