Thoughts about "Compile-time types" talk

Alex AJ at gmail.com
Thu May 16 03:52:11 UTC 2019


On Monday, 13 May 2019 at 08:35:39 UTC, Martin Tschierschke 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?
>
> The solution was from someone else, in the forum, but it 
> resulted in the following code:
>
> auto reg(alias var)()
> {
>        static if (__traits(compiles, {enum ctfeFmt = var;}) )
>          {
>                 // "Promotion" to compile time value
>                 enum ctfeReg =  var ;
>                 pragma(msg, "ctRegex used");
>                 return(ctRegex!ctfeReg);
>
>           }else{
>                 return(regex(var));
>                 pragma(msg,"regex used");
>           }
> }
>
> The trick is the alias var, which then can be checked,
> with
>       __traits(compiles, {enum ctfeFmt = var;}
>
> is it an immutable value present at compiletime or not.
>
>
> Now you may use
>
> auto myregex = reg!(Regex_expression);
>
> At every place in your code.
>
> And depending on the question, does it compile to the ctfeReg 
> or not the version is selected.
>
> So there is away to promote a ctVariable to runtime, if this 
> would be possible with a runtime value, too, you would get rid 
> of the '!' -syntax.
>
> Regards mt.

The compiler should do this all internally. All it has to do is 
keep track of simple "Known" state of a variable.

Any expression or line that is compiled uses other things. The 
compiler has to known these things and it keeps track of them in 
the AST. But it should also know if those things are known.

That is what CTFE basically does and also how things get 
optimized...

But somewhere it breaks down. It most likely does this because of 
the way things are specified in D as being RT.

e.g., ctRegex and regex.... two different things that break the 
unity.

The compiler isn't going to know they are related and hence why 
you had to build a relation.

This is a problem of the language itself.

All programming should start as if it were CT with RT being an 
after effect. One would even reason about obvious RT things like 
readln as if they were compile time. One should even think of 
program execution as just finishing the compilation process. We 
should even have compilers written with this mentality and 
languages designed with it. It puts the proper emphasis on 
writing code.

One could say that programming language design got it backwards.. 
we started with RT programming when it should have been about CT. 
[Of course when dealing with punch cards it's hard to get it 
right]

By starting with CT and assuming everything is CT until it is 
proven not to be, the compiler knows it can optimize things(until 
it can't). When one starts with RT and assumes everything is RT 
there is no optimization that can take place. Obviously most 
languages and compilers use some blend.

Functional languages tend to focus more in the CT side and then 
have special cases like IO and state that deal with the RT.


A prototypical example would be readln.

Why is that RT? Does it have to be? What if you want to mock up a 
program, then the compiler could optimize it out! I don't mean.

//string s = readln();
s = "mock".

But
string s = readln();

and some point inside readln it reads a mock file at compile time 
because of a flag and returns mock. (and we don't have to modify 
source code to switch from RT to CT)

As one digs down in to readln there will eventually be some code 
that cannot be compiled down in to a known state at compile time. 
The compiler should be able to figure this out... e.g., it there 
is an OS call and all OS calls are marked as "RT". (but we could 
replace those calls with a mocking set that then is known at 
compile time and then it could be reduced)

All such things though require the compiler to be aware... they 
are far more aware than ever before, but only will get better 
over time as people make improvements, but it does require people 
to realize what can be improved.






More information about the Digitalmars-d mailing list