type variables

[Bruce Carneal]

On Sunday, 2 August 2020 at 23:04:45 UTC, Stefan Koch wrote:
> On Sunday, 2 August 2020 at 20:42:35 UTC, Paul Backus wrote:
>> On Sunday, 2 August 2020 at 20:27:53 UTC, Bruce Carneal wrote:
>>>
>>> I think it's all about readability given the performance 
>>> constraints.
>>>
>>> Your type function example earlier in this thread employs 
>>> iteration and is dead simple.  Not much to improve there.
>>
>> You're conflating two separate issues. The existing 
>> alternative to using a TypeBuilder + iteration is `static 
>> foreach`--which is also iterative.
>>
>> The question you should answer, if you want to convince people 
>> that TypeBuilder (or something like it) is worth adding, is 
>> "how is this better than `static foreach` and `static if`?"
>
> static foreach and static if come with
> compile time performance prices to pay.
>
> it comes down to having to do semantic processing in a 
> piece-wise fashion multiple times.
>
> The type function approach I am working on does semantic 
> processing of invariant parts only once.
>
> Whereas the static foreach body cannot know about invariant 
> regions, (that's a general statement (in special cases it might 
> be possible to implement such awareness (I would not advise it 
> however)))

I'd add that working with sets of types should become very 
readable and efficient.  Doable now but dead simple when types 
live as normal objects in the compile time environment.  Arrays, 
slicing, all the good stuff.

I don't see a problem with operating with these objects at 
runtime either.  In process code gen wouldn't be available, at 
least not absent something like a LLVM/jit hookup, but you could 
play with it all in a more debuggable environment.