> So this is basically a missing piece of functionality for expression-template-based solutions for automatic differentiation?
Yes, I would say so. It is the minimum requirement needed for writing an automatic differentiation tool that produces highly efficient object code.
On Tue, 22 Dec 2020 at 01:43, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> 1) What do you use to solve such problems today?
> 2) Would the introduction of this language facility perhaps, vaguely
> guessing at a possible answer to (1), to be able to
> avoid using a compiler-specific solution or a custom parser?
>
> A further remark: we are yet fairly far from being able to introspect
> and analyze function bodies, sequences of statements
> and expressions, that is. Based on a brief look at the talk this might
> fall into that bucket that we hope to get at later
> on, but perhaps there's something about the answer to the question (1)
> above that makes this more straightforward
> than full expression/statement-reflection?
Ha, having seen all of the talk, I may have gotten quite a bit ahead
of things there. So this is basically
a missing piece of functionality for expression-template-based
solutions for automatic differentiation?