Discussion on static reflection syntax in C++

[Stefan Koch]

On Monday, 22 February 2021 at 23:44:45 UTC, Paul Backus wrote:
> On Monday, 22 February 2021 at 23:32:39 UTC, Max Haughton wrote:
>> On Monday, 22 February 2021 at 21:59:41 UTC, Paul Backus wrote:
>>> On Monday, 22 February 2021 at 21:34:47 UTC, Max Haughton 
>>> wrote:
>>>> On Monday, 22 February 2021 at 16:27:49 UTC, Andrei 
>>>> Alexandrescu wrote:
>>>>> Of possible interest:
>>>>>
>>>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2320r0.pdf
>>>>
>>>> Exposing reflection information via CTFE seems like a much 
>>>> more workable solution - i.e. you just write regular D code. 
>>>> This is what Stefan's work effectively culminates in.
>>>
>>> Or, in other words: procedural macros. (Shh, don't tell 
>>> Walter.)
>>
>> They aren't macros though - at least in my mind a macro is 
>> effectively a shortcut into the bowels of the compiler whereas 
>> in this case the compiler wouldn't care what you do with the 
>> information after it gives it to you since it's just regular D 
>> code.
>
> Aren't macros in Lisp just regular Lisp code, too? :)
>
> As far as I'm concerned, a procedural macro is a function that
>
> 1. runs at compile time,
> 2. takes AST nodes as input, and
> 3. produces AST nodes as output.
>
> Type functions fit those criteria perfectly. Currently, they 
> only work on a subset of AST nodes (types), so they're not a 
> *complete* implementation of procedural macros, but generalize 
> them enough and that's what you'll get.

They don't exactly take AST nodes.
They take a constrained (stabilized) datastructure which reflects 
a subset of the ast.
At least conceptually.
They don't create ast nodes, but regular values, which may be 
converted to ast-nodes in the case where they are statically 
available. (currently only types)

My currently exploration leads me to a path where you can 
_extend_ open scopes within typefunction by using special 
functions which map provide a stable mapping to compiler 
intrinsics.
such as __struct* __add_struct(string name, __symbol[] members);
the __struct* will not be a proper struct type unless
__type__ __add_to_scope(__scope Scope, __struct* s);
has been called.

At which point any modification of the __struct* is an error and 
will abort compilation.

I am still searching for a solution which is more declarative, 
but I fear for heavy usage (10_000 new types and declarations 
added) scenarios the procedural imperative style is just more 
optimizable.

I am always open to syntax suggestions, as I don't like the one I 
have :)