Thoughts about "Compile-time types" talk

[Alex]

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:
>>> On Friday, 10 May 2019 at 00:33:04 UTC, H. S. Teoh wrote: 
>>> [...]
>>> > I haven't fully thought through this yet, but the basic 
>>> > concept is that there should be *no need* to distinguish 
>>> > between compile-time and runtime in the general case, 
>>> > barring a small number of situations where a decision has 
>>> > to be made.
>>> [...]
>>> I was thinking and working in the same direction,
>>> when using regEx you can use the runtime (RT) or the compile 
>>> time (CT)
>>> version, but why not let the compiler make the decisions?
>>
>> It would be great if the compiler could make all of the 
>> decisions, but I think at some point, some level of control 
>> would be nice or even necessary.
>
> 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.

The reason why it confuses you is that you are thinking in the 
wrong paradigm.


To unify requires a language that is built under the unified 
concept.

D's language was not designed with this unified concept, but it 
obviously does most of the work because it it does do CT 
compilation. Most compilers do. Any optimization/constant folding 
is CT compilation because the compiler knows that something can 
be computed.

So ideally, internally, a compiler would simply determine which 
statements are computable at compile time and simplify them, 
possibly simplifying an entire program... what is not known then 
is left to runtime to figure out.

D already does all this but the language clearly was not designed 
with the intention to unify them.

For example,

int x = 3;
if (x == 3) fart;

Hear the compiler should be able to reason that x = 3 and to 
optimize it all to

fart;


This requires flow analysis but if everything is 100% analyzed 
correctly the compiler could in theory determine if any statement 
is reducible and cascade everything if necessary until all that's 
left are things that are not reducible.

It's pretty simple in theory but probably very difficult to 
modify a pre-existing compiler that was designed without it to 
use it.

Any special cases then are handled by special keywords or 
syntaxes... which ideally would not have to exist at all.

Imagine if all statements in a program were known at compile 
time, even things like readln(as if it could see in to the 
future)...

The a compiler would compile everything down to a single return. 
It could evaluate everything, every mouse click, every file io or 
user choice, etc...

A program is simply a compiler that is compiling as it is being 
run, the users adding in the missing bits.