Thoughts about "Compile-time types" talk

[Ola Fosheim Grøstad]

On Thursday, 16 May 2019 at 09:35:16 UTC, Alex wrote:
> For example, in D we have
>
> enum x = 4;
> and
> int y = 4;
>
> That is explicitly two different programming contexts. On CT 
> and the other RT. But that is the fallacy. They are EXACTLY 
> identical programmatically.
>
> Only when y is modified at some point later in the code does 
> things potentially change. enum says we will never change x at 
> CT... but why can't the compiler figure that out automatically 
> rather than forcing us to play by it's rules and have a 
> separate context?

I agree with your basic goals.

But there are a few issues:

1. to avoid the special-casing you need to add type-variables as 
proper variables in the language. Then you can have functions as 
meta-level type-constructors.

2. you need to provide a construct for ensuring that a value is 
resolved at compile time.

3. how do you ensure that the library code you write is 
structured in a way that doesn't seem to arbitrarily break?

4. corollary of 3, how to you ensure that library code doesn't 
generate slow code paths spent on resolving typing information at 
runtime?


Anyway, I don't disagree with your goals, but you would have a 
completely different language.