[cfe-dev] Reflection/metaparsing implem

[David Blaikie via cfe-dev]

On Wed, Nov 13, 2019 at 12:42 PM Herb Sutter <herb.sutter at gmail.com> wrote:

> I don’t want to weigh in for/against any particular Clang proposal, but
> FWIW regarding this:
>
>
>
> > Not all demands must be satisfied.
>
>
>
> True, but in this case…
>
>
>
> > Other languages (I'm looking at Java) have reflection without expression
> reflection
>
>
>
> … IMO we already know that we will need statement and expression
> reflection, to enable uses like autodiff. For example, in the ML field I’ve
> encountered C++ developers who would prefer to use C++ because of its AOT
> compilation performance, but who of have switched to other languages such
> as Julia primarily because of compile-time autodiff (and more generally for
> the broader class of AI/ML transformations that includes autodiff) where
> today in C++ doing it by hand-coding the derivative function greatly slows
> down the experimentation phase of an ML project… which otherwise would
> actually be faster with AOT C++.
>
>
>
> At least one of the proof-of-concept C++ reflection implementations
> (Circle) already support statement/expression reflection and autodiff.
>
>
>
> For statements and expressions, my impression is that reflection is pretty
> straightforward to specify (here’s another meta::info API) and the primary
> thing to watch for is that the current proposals for injection (generated
> code, generative programming) will extend well to statements and
> expressions, again using autodiff as a litmus test example of what we want
> to be able to express.
>

Ah, fair enough - thanks for the context! Yeah, I've not looked in any
great detail at what's being proposed for standardization, or what its
goals are - but intended to make the point that there are useful points in
the reflection surface area that aren't "full AST fidelity". I've no doubt
Richard Smith & other Clang folks who are (more than I) involved with the
committee do a far better job than I at advocating for the nuances of
implementation complexity/flexibily/future-proofing & working to ensure not
too much of the implementation details get baked into a language feature
while balancing the needs of users.

(compile time symbolic differentiation does sound like fun, to be sure -
didn't know that was on the table/part of the motivation here)

- Dave


>
>
> Herb
>
>
>
>
>
> *From:* cfe-dev <cfe-dev-bounces at lists.llvm.org> *On Behalf Of *David
> Blaikie via cfe-dev
> *Sent:* Tuesday, November 12, 2019 11:42 AM
> *To:* David Rector <davrec at gmail.com>
> *Cc:* Clang Dev <cfe-dev at lists.llvm.org>
> *Subject:* Re: [cfe-dev] Reflection/metaparsing implem
>
>
>
>
>
>
>
> On Tue, Nov 12, 2019 at 6:04 AM David Rector <davrec at gmail.com> wrote:
>
> Fair enough.
>
>
>
> As I say in my readme, I recommend those who need full reflection
> facilities — up to their class templates, down to the individual IfStmts
> etc. in their function defs — to use my implementation and simply isolate
> dependencies on future standards into their own helper functions.  You can
> do everything now!  No need to complain to or pressure Andrew (who has done
> some extraordinary work by the way) about what isn’t yet reflected.
>
>
>
> *Eventually* the standard will support reflecting everything, years hence,
> whatever anyone says now.  The demands will just never stop until
> everything is reflected.
>
>
>
> Not all demands must be satisfied. Other languages (I'm looking at Java)
> have reflection without expression reflection, for example, so far as I
> know.
>
>
>
>  Start writing your algorithms now, switch your helper functions to
> whatever standards they decide later.
>
>
>
> Regarding parallel naming I think we’re talking about different things —
> what we’re doing now IS a parallel naming structure.
>  meta::is_constexpr(reflinfo) is a parallel of FunctionDecl::isConstexpr()
> etc.  A full parallel structure of every property is what we’re looking at
> building.  If everyone’s looked hard at that eventuality and are okay with
> maintaining that, then I suppose I have no cause to complain — maybe it’s
> not as hard as I imagine.
>
>
>
>
>
>
>
> On Nov 12, 2019, at 8:01 AM, Andrew Sutton <asutton.list at gmail.com> wrote:
>
>
>
>
>
> I argue the standards should be based on the clang AST.  Clean it up first
> of course — and yes that alone would be extraordinarily difficult.  But
> it’s also very difficult to build a gigantic parallel naming system for
> reflection properties.  And then to maintain it long term…
>
>
>
> Best to look hard at what lies ahead, and bite the bullet now.  Clean up
> the AST, define the standard via it.  (And c’mon we all know those AST
> nodes have a lot of flab to go with all their muscle; clang would benefit
> too after we all finish grumbling about the changes.)  Other compilers can
> do a parallel naming system or adjust their own ASTs to match clang’s
> naming system — doesn’t need to add any work for them.
>
>
>
> This is a non-starter for standardization. There are significant and
> generally incompatible differences in the internal representations of C++
> among the different vendors and no will to standardize or even informally
> adopt a common representation. Even if there were interest in doing so, the
> engineering cost would be prohibitive, as it would essentially require
> gutting and rewriting huge swaths of the compiler (and in GCC's case,
> possibly the middle-end). Parallel naming is also unlikely because of
> memory requirements.
>
>
>
> You have the same problem with compiled module interfaces, which serialize
> the internal representation.
>
>
>
> Andrew
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20191113/47af9c53/attachment.html>