Date: Tue, 20 Feb 2024 19:33:30 -0000
Hey everyone,
First of all, thanks to Jean-Baptiste and to Code Reckons for sharing the CppMeta compiler! This looks like awesome work, and I'm excited to read your subsequent articles regarding the project.
As one of the co-authors of P2996, I think that CppMeta demonstrates many of the powerful features we hope to bring to C++ once the foundation for Static Reflection has been laid: Injective metaprogramming, and reflection over more general expressions, will let C++ address problems like lambda serialization, automatic differentiation, proxy class generation, and more. Andrew Sutton's P2237 ("Metaprogramming") paper detailed one vision for how such features could be built on top of P2996-style reflection.
One thing that I feel is coming into sharper focus is just how ambitious of a change P2996 already represents. Although it's easy to at first see our paper as just a pair of new operators and a handful of functions, the number of cross-cutting concerns is quite large: Splices of expressions can appear in member access expressions; splices of namespaces and types can appear as the leading component of nested name specifiers; special care is needed when a splice appears as the operand of the reflection operator; special rules are needed when using a splice as a template argument; and since std::meta::info is a scalar type, any of these things can be dependent on a template parameter (including namespaces!).
I think that as folks get a good look at implementations of P2996, and at the proposed wording that has started to take shape in the R2 revision (still missing quite a bit of language), they'll see just how many changes need to be stitched together to give the impression that reflection "just works." P2996 feels to me like the right level of ambition for C++26, but it will still take a lot of hard work and a little bit of luck for it to land in time.
After that? I'd love to see some of the ideas from CppMeta revisited. As I discussed in P3010, I share the project's enthusiasm for "typeful" value-based reflection. I recall that SG7 expressed support in Kona for eventually adopting a family of such types with std::meta::info as the "common denominator". I hope that more folks continue to explore what such families of reflection types might look like: It might take some time to find the right "granularity" of types (e.g., a 'type_t' seems like a given, but the need for a 'pointer_type_t' is less obvious to me), and to ensure that the proposed types aren't tied too closely to any given implementation's internal data structures. In the meantime, Example 17 from P2996R2 suggests one (admittedly less ergonomic) means of experimenting with typeful reflection types on top of P2996.
I'm excited to hear more about CppMeta, and I hope its design helps to inform what source code injection and typeful reflection might look like going forward!
Best,
---Dan Katz
From: sg7_at_[hidden] At: 02/17/24 16:04:02 UTC-5:00To: sg7_at_[hidden]
Cc: jeanbaptiste.vallon_at_[hidden]
Subject: Re: [SG7] CodeReckons CppMeta compiler
Hello everyone,
The differences can be quickly summarized as follows :
- the reflection API is typed
- the reflection domain includes statements and expressions (so we're able to traverse a function's body, for example)
- anything that can be reflected, can be constructed/injected. so we can create expressions, statements, or declarations. Our use cases cover operators generation/interface generation (member functions synthesis), symbolic differentiation (expressions traversal and synthesis), string matching (statements synthesis), and static analysis (statements/expressions traversal, inspection of functions parameters), among other things.
- we can emit diagnostics at compile-time, and transform value of builtin types to text (we've also constexpr-ised std::format to help emit diagnostics)
This is of course a very brief summary of the differences, and they will hopefully be better demonstrated by the articles.
-Jean-Baptiste
Le ven. 16 févr. 2024 à 20:57, David Sankel via SG7 <sg7_at_[hidden]> a écrit :
Thanks for sending this out Hana. It would be great if someone could succinctly summarize how this differs from what was already forwarded to EWG.
On Tue, Feb 13, 2024 at 11:44 AM Hana Dusíková via SG7 <sg7_at_[hidden]> wrote:
Hello SG7!
Jean-Baptiste Vallon Hoarau and Joel Falcou recently contacted me as they work on on a prototype of reflection (different than P2996 as they started a while ago) and it's an interesting design. They just announced a blogpost about it.
Hana
Code Reckons
codereckons.com
First of all, thanks to Jean-Baptiste and to Code Reckons for sharing the CppMeta compiler! This looks like awesome work, and I'm excited to read your subsequent articles regarding the project.
As one of the co-authors of P2996, I think that CppMeta demonstrates many of the powerful features we hope to bring to C++ once the foundation for Static Reflection has been laid: Injective metaprogramming, and reflection over more general expressions, will let C++ address problems like lambda serialization, automatic differentiation, proxy class generation, and more. Andrew Sutton's P2237 ("Metaprogramming") paper detailed one vision for how such features could be built on top of P2996-style reflection.
One thing that I feel is coming into sharper focus is just how ambitious of a change P2996 already represents. Although it's easy to at first see our paper as just a pair of new operators and a handful of functions, the number of cross-cutting concerns is quite large: Splices of expressions can appear in member access expressions; splices of namespaces and types can appear as the leading component of nested name specifiers; special care is needed when a splice appears as the operand of the reflection operator; special rules are needed when using a splice as a template argument; and since std::meta::info is a scalar type, any of these things can be dependent on a template parameter (including namespaces!).
I think that as folks get a good look at implementations of P2996, and at the proposed wording that has started to take shape in the R2 revision (still missing quite a bit of language), they'll see just how many changes need to be stitched together to give the impression that reflection "just works." P2996 feels to me like the right level of ambition for C++26, but it will still take a lot of hard work and a little bit of luck for it to land in time.
After that? I'd love to see some of the ideas from CppMeta revisited. As I discussed in P3010, I share the project's enthusiasm for "typeful" value-based reflection. I recall that SG7 expressed support in Kona for eventually adopting a family of such types with std::meta::info as the "common denominator". I hope that more folks continue to explore what such families of reflection types might look like: It might take some time to find the right "granularity" of types (e.g., a 'type_t' seems like a given, but the need for a 'pointer_type_t' is less obvious to me), and to ensure that the proposed types aren't tied too closely to any given implementation's internal data structures. In the meantime, Example 17 from P2996R2 suggests one (admittedly less ergonomic) means of experimenting with typeful reflection types on top of P2996.
I'm excited to hear more about CppMeta, and I hope its design helps to inform what source code injection and typeful reflection might look like going forward!
Best,
---Dan Katz
From: sg7_at_[hidden] At: 02/17/24 16:04:02 UTC-5:00To: sg7_at_[hidden]
Cc: jeanbaptiste.vallon_at_[hidden]
Subject: Re: [SG7] CodeReckons CppMeta compiler
Hello everyone,
The differences can be quickly summarized as follows :
- the reflection API is typed
- the reflection domain includes statements and expressions (so we're able to traverse a function's body, for example)
- anything that can be reflected, can be constructed/injected. so we can create expressions, statements, or declarations. Our use cases cover operators generation/interface generation (member functions synthesis), symbolic differentiation (expressions traversal and synthesis), string matching (statements synthesis), and static analysis (statements/expressions traversal, inspection of functions parameters), among other things.
- we can emit diagnostics at compile-time, and transform value of builtin types to text (we've also constexpr-ised std::format to help emit diagnostics)
This is of course a very brief summary of the differences, and they will hopefully be better demonstrated by the articles.
-Jean-Baptiste
Le ven. 16 févr. 2024 à 20:57, David Sankel via SG7 <sg7_at_[hidden]> a écrit :
Thanks for sending this out Hana. It would be great if someone could succinctly summarize how this differs from what was already forwarded to EWG.
On Tue, Feb 13, 2024 at 11:44 AM Hana Dusíková via SG7 <sg7_at_[hidden]> wrote:
Hello SG7!
Jean-Baptiste Vallon Hoarau and Joel Falcou recently contacted me as they work on on a prototype of reflection (different than P2996 as they started a while ago) and it's an interesting design. They just announced a blogpost about it.
Hana
Code Reckons
codereckons.com
-- SG7 mailing list SG7_at_lists.isocpp.org https://lists.isocpp.org/mailman/listinfo.cgi/sg7 -- SG7 mailing list SG7_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/sg7 -- SG7 mailing list SG7_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/sg7
Received on 2024-02-20 19:33:31