Thoughts about "Compile-time types" talk

[Alex]

On Thursday, 16 May 2019 at 08:12:49 UTC, NaN wrote:
> On Wednesday, 15 May 2019 at 18:57:02 UTC, Alex wrote:
>> On Wednesday, 15 May 2019 at 18:31:57 UTC, NaN wrote:
>>> On Tuesday, 14 May 2019 at 17:44:17 UTC, H. S. Teoh wrote:
>>>> On Mon, May 13, 2019 at 08:35:39AM +0000, Martin 
>>>> Tschierschke via Digitalmars-d wrote:
>
>>> If you envisage a regular if statement being able to be both 
>>> CT/RT depending on whether the value inside its brackets is 
>>> known at CT or not what do you do about whether it introduces 
>>> a new scope or not? Static if does not, but regular if does, 
>>> if you want them unified something has to give.
>>
>> That is not true.
>>
>> Any type is either known at "CT" or not. If it is not then it 
>> can't be simplified. If it is known then it can. A compiler 
>> just simplifies everything it can at CT and then runs the 
>> program to do the rest of the simplification.
>
> You're conflating how it is implemented with the semantics of 
> the actual language. I understand how static if works, what im 
> saying is if you want to just have "if" and for the compiler to 
> infer whether it's CT or RT, then you have the same construct 
> with different semantics depending on the context.

No, you don't get it.

We are talking about a hypothetical compiler that doesn't have to 
have different contexts. In D, the contexts arbitrarily separated 
in the language...

What we are ultimately talking about here is that CT and RT is 
not two different concepts but one concept with some very minute 
distinction for RT.

As a programmer you shouldn't care if something is CT or RT and 
hence you shouldn't even know there is a difference.

What are you saying is that you have one if and two contexts. 
What I'm saying is  hat you have one if and one context. That the 
CT programming and runtime programming are NOT treated as being 
two different universes with some overlap but the same universe 
with a slight boundary.

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?


CTFE sort of blends the two and it is a step in the direction of 
unifying CT and RT. Of course, it will never remove enum from the 
language...

The point is that D, and most programming languages, create a 
very strong distinction between CT and RT when the truth is that 
there is virtually no distinction.

This happens because programming languages started out as almost 
entirely RT and CT as added on top of them. This created the 
separation, not because there actually is a theoretical one. In 
the context of category theory, RT is simply the single unknown 
category in which any code that depends on must be deferred from 
computation until it is known(which occurs when we run the 
program and "compilation" can finish).

The problem is that 99.9% of programmers think almost entirely in 
terms RT, even when they do CT programming. For them a compiler 
just takes code and spits out machine code... but they do not see 
how it is all connected. A cpu is also a compiler and part of the 
compilation process. It takes certain bit patterns and compiles 
them down to others. Seeing things in this larger process shows 
one the bigger picture and how there are many artificial 
boundaries and some are no longer needed.