Thank you for your comments.

Regarding the first: my use case is compile-time automatic differentiation
(AD). I gave a talk <https://www.youtube.com/watch?v=31mQmUryw50&t=3504s> on
the approach at a London C++ meetup, and at a Euro AD workshop [slides
<http://www.autodiff.org/Docs/euroad/22nd%20EuroAd%20Workshop%20-%20Dominic%20Jones%20-%20Compile%20time%20differentiation%20in%20C++.pdf>
].

The gist of it is that I want to be able to evaluate an expression from its
root to its terminals. This is the opposite of what one normally wishes to
do, but it just is the nature of the so-called 'adjoint' method of
automatic differentiation. Doing this naively, one ends up performing
duplicate evaluations when a term is used repeatedly.

Consider the code corresponding to Figure 1 (I now realise I should have
included the code snippet in the paper!): the term 'ab' occurs twice in the
expression for 'result'. In typical expression evaluation, 'ab' is
evaluated once then its result used in many places. However, in
back-propagation evaluations (like those found in adjoint automatic
differentiation), evaluation begins at 'result' and propagates to the
terminals 'a' and 'b'. The problem is that the back-propagation will visit
the sub-expression tree for 'ab' twice since it occurs twice upstream.

float c0;
float c1;
auto ab = a * b;
auto result = (c0 + ab) / (c1 + ab);

Regarding the second point: I came across Andrew Sutton's paper, P2237R0,
after submitting my own. Whilst skimming it I saw something that may be
doing what I am proposing, namely 'meta::location_of(e)', p15 ff. Are the
reflection mechanisms you are referring to those mentioned by Andrew in his
paper or are you referring to another language proposal? If it is another,
I'd be grateful if I could get a link to the paper.

I agree that if there are not sufficiently broad use case examples for my
proposal then it does not warrant further consideration; amassing a broad
range of use cases is something I still need to work on. (Klaus Iglberger,
I believe, has a use case for his math library 'Blaze' which I need to ask
him for.) However, presently, I don't know how the same end could be
achieved without a top level API function. Early on, I thought it could be
by proposing a language extension whereby `address of' in a constexpr
context would return a constexpr variable ID, much like what varid would
do. However, even with this, a second language change would need to be
made, one whereby a constexpr function could return a constexpr result
despite taking non-constexpr arguments (i.e. resolving the compilation
error presented in Listing 3).

In response to your final comment: unfortunately, only having equality
wouldn't do; it would be minimally useful, facilitating expression
transformations for only trivial expressions, such as 'c0*c1' or 'c0*c0',
but nothing more complicated than that.

Regards,
Dominic


On Mon, 21 Dec 2020 at 19:38, Ville Voutilainen <ville.voutilainen_at_[hidden]>
wrote:

> On Sun, 20 Dec 2020 at 20:47, Dominic Jones via SG7
> <sg7_at_[hidden]> wrote:
> >
> > Hello,
> >
> > I was wondering if I may submit a language proposal to the SG7 mailing
> list, please? I have never been involving in library or language proposals
> (or in any way with ISO C++), so I am not so sure this is the way to go
> about things.
> > I have read the documentation on
> https://isocpp.org/std/submit-a-proposal , but I have not attended a
> committee meeting. If this requirement presently stands, may I find out how
> to attend the next meeting, please?
>
> Well, howdy, welcome.
>
> If you're in UK, perhaps Roger Orr (cc:ed) could help with the
> mechanics of attendance? Study group attendance
> doesn't require the full mechanics, though - study groups can have any
> interested experts attend.
>
> Some questions (not criticisms, just questions) about the proposal:
>
> 1) I'm still a bit baffled how this would be used, I mean in code. Do
> you have any more concrete examples of where this
> facility is important to have?
>
> 2) I would remotely-vaguely think that it might be possible to get
> this information via the reflection of a variable. If you
> have that reflection, you can check the name and the scope of a
> variable - if those are the same, you have the same
> variable. I don't know whether our proposed reflection APIs have any
> particular "reflects the same entity" mechanism,
> but perhaps that would be worth looking at or thinking about. Having
> the identifier be a top-level API function is.. ..a
> bit puzzling to me, because I wouldn't expect this to be all _that_
> common use of compile-time information?
>
> One of the reasons I ruminate about (2) is that I don't fully grasp
> (1). If all you need is equality, that may be already
> doable, or can easily fit into the existing APIs. If you have more
> needs for the id than just (in)equality with other entities,
> then the picture may change. May. May not.
>