TypeFunction example creatiing a conversion matrix

Stefan Koch uplink.coder at googlemail.com
Thu Oct 1 17:03:03 UTC 2020


On Thursday, 1 October 2020 at 16:49:20 UTC, Andrei Alexandrescu 
wrote:
> On 10/1/20 12:12 PM, Steven Schveighoffer wrote:
>> 
>> The difference I see is that reification/dereification has to 
>> rebuild everything that is already in the compiler, but at 
>> runtime. And it has to make sure the functionality is 
>> identical. You are using the compiler to build another type 
>> introspection system, but just so you can do CTFE based things.
>> 
>> It reminds me of "modern" web applications which take over 
>> browser functionality (page navigation, etc.) and reimplement 
>> it in javascript.
>> 
>> If we can't get a system that allows dereifcation DURING 
>> function execution, then I think type functions are a much 
>> better solution. There's no reason to reimplement what the 
>> compiler already does. Type functions are cleaner, clearer, 
>> and much more efficient.
>
> Hmmm... interesting. It's also been my accumulated perception 
> that much metaprogramming is in fact "doing things in the 
> target language that normally only the compiler writer is 
> empowered to do". For example, the implementation of switch on 
> strings has been entirely shipped to druntime 
> (https://github.com/dlang/druntime/blob/master/src/core/internal/switch_.d), which does everything a compiler normally does with optimizing a switch: looks at the number and content of cases, defines distinct strategies depending on them, etc. In smaller form __cmp is the same story (optimizes comparison depending on the types involved) and many other cases. My take is that that's a good thing, because I don't need to be in the compiler do do powerful things.
>
> Of course std.traits would be chock full of this kind of stuff, 
> as no doubt most artifacts in there are present in the compiler 
> internals, or easily extractable therefrom. In that respect, 
> __traits is an exercise in "what is the minimum set of 
> primitives the compiler needs to expose, in order to allow 
> regular D code to do everything else that the compiler normally 
> does?" It's a bottleneck design (complex entities communicating 
> through a narrow interface). Probably not very well done 
> because __traits keep on getting a variety of things that are 
> difficult to decide upon. I have no good litmus test on a 
> proposed __trait whether it's deserving, the right thing, the 
> most enabling, etc. On the other hand, std.traits did allow us 
> to do things that would be quite onerous to put in the language 
> definition and/or compiler implementation. On the whole this 
> bottleneck design has been quite enabling.
>
> The difficulty/challenge of crossing of the barrier from types 
> to values and back is good to appreciate when doing things like 
> mixed compile-time/run-time uses and integration with 
> type-oriented facilities (such as those in std.traits itself).

Please do try to express yourself more concisely.
As well as close to the topic.
I cannot make heads or tails of your writing.

This is not about std.traits.
This is more about making std.traits superfluous.
Integrating type based programming so well with the language that 
there is almost no barrier when crossing to type-object land.
The serialized "reified" type is given behavior as close as 
possible to a real type.
Which simplifies the interface, and keeps it intuitive.

All you can do with a type the compiler can already do.
It has to be able to do it.
So at CTFE I merely tap into what the compiler already does.
There's very little code duplication and even the bit there is 
can be improved incrementally making the compiler more modular.


More information about the Digitalmars-d mailing list