On 21/02/2024 01.19, Robin Rowe via SG7 wrote:
> Thank you for posting the insightful thread about CppMeta as a potential
> implementation of C++ reflection. I'd like to ask about bringing code
> reflection to C.
>
> I program in both C++ and C. I am imagining, for code reflection in C, a
> new preprocessor operator ### (maybe called code-string) to go with #
> (stringize) and ## (concatenate).

Please read [lex.phases] (in C++) or 5.1.1.2 (in C23).
The preprocessor runs way earlier than when C tokens are recognized as such.

This won't work absent major surgery to foundational concepts of C
(and C++, if a compatible facility should be introduced there).

Jens


> However, unlike # and ##, using ###
> isn't limited to within a #define macro...
>
> // C preprocessor ### operator potential example:
>
> enum Color { red, green, blue };
>
> struct Point
> { int x;//some comment
> int y;
> int z;
> };
>
> void foo(int x);
>
> const char* s = ###(Color);
> puts(s);
> /* output:
> enum Color { red, green, blue };
> */
> s = ###(Color.2);
> puts(s);
> /* output:
> enum blue = 2;
> */
> s = ###(Point);
> puts(s);
> /* output:
> struct Point
> { int x;//some comment
> int y;
> int z;
> };
> */
> s = ###(Point.x);
> puts(s);
> /* output:
> int x;
> */
> s = ###(Point.1);
> puts(s);
> /* output (member #1):
> int y;
> */
> s = ###(Point.);
> puts(s);
> /* output (how many members in struct):
> 3
> */
> s = ###(foo);
> puts(s);
> /* output:
> void foo(int x);
> */
> s = ###(Hello); //compile-time error, Hello doesn't exist
>
> Code-string hasn't been proposed yet. Still at idea stage. CppMeta is
> much more sophisticated, seems too sophisticated for C. What are the
> most significant features of CppMeta missing in ### concept?
>
> Thoughts?
>
> Robin Rowe
> Beverly Hills, California
> *Chairman ISO WG21 SG14 C++ Banking and Financial Systems Subcommittee
>
> On 2/20/2024 11:33 AM, Dan Katz (BLOOMBERG/ 919 3RD A) via SG7 wrote:
>> 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:00
>> To: sg7_at_[hidden] <mailto:sg7_at_[hidden]>
>> Cc: jeanbaptiste.vallon_at_[hidden] <mailto: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] <mailto: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] <mailto: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
>>
>> <https://www.codereckons.com/articles/65cbc0511318c3d21078737b>
>> Code Reckons
>> <https://www.codereckons.com/articles/65cbc0511318c3d21078737b>
>> codereckons.com
>> <https://www.codereckons.com/articles/65cbc0511318c3d21078737b>
>> favicon.ico
>> <https://www.codereckons.com/articles/65cbc0511318c3d21078737b>
>>
>>
>> --
>> SG7 mailing list
>> SG7_at_[hidden] <mailto:SG7_at_[hidden]>
>> https://lists.isocpp.org/mailman/listinfo.cgi/sg7
>> <https://lists.isocpp.org/mailman/listinfo.cgi/sg7>
>>
>> --
>> SG7 mailing list
>> SG7_at_[hidden] <mailto:SG7_at_[hidden]>
>> https://lists.isocpp.org/mailman/listinfo.cgi/sg7
>> <https://lists.isocpp.org/mailman/listinfo.cgi/sg7>
>>
>> --
>> SG7 mailing list
>> SG7_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/sg7
>>
>>
>>