CTFE history

[Don]

bearophile wrote:
> Michal Minich:
> 
>> see thread "Compile time function execution..." at http://www.digitalmars.com/d/archives/ digitalmars/D/index2007.html. In the previous discussion you can see this idea forming (I searched for the word "compile").<
> 
> Thank you, I have found and read some of those threads. It seems the idea of CTFE comes from 3-4 persons, and it has evolved progressively from finding the limits of template-based execution of regex, it was not invented in a single step by a single person. It's indeed an interesting story, worth writing a little article about. The "constexpr" has shown up in the threads only after CTFE was already in DMD, so maybe there is no direct influence of it.

There was absolutely no influence from constexpr.

The story starts here:

http://www.digitalmars.com/d/archives/digitalmars/D/learn/1991.html

As far as I can tell, at the very beginning of D, when it was still 
called the "Mars programming language", the key idea of Mars was dynamic 
arrays and array slices. In the oldest file in the DMD source code, they 
are called "Jupiter arrays".

An unforseen consequence of this support for slicing was that the 
compiler had considerable built-in semantics for array and string 
processing. Many metaprogramming things just worked. In fact, so many 
things worked, that the gaps became obvious, and so we filled them in.
It all felt very natural.
Essentially, we followed the implications of the existing language, and 
ended up with CTFE.


> After reading some of those threads I have a new question. 
 > Let's say I have a function bad() that I want to run at CT, it calls 
two functions, a slow CT function named aVerySlowCTFunction() and a 
function notCTExecutable() that can't be run at CT:
> int bad(int x) {
>     auto y = aVerySlowCTFunction(x); // good
>     return notCTExecutable(y); // bad
> }
> 
> enum int z = bad(120);
> 
> void main() {}
> 
> 
> Now the compiler runs aVerySlowCTFunction() and only later it finds that notCTExecutable() can't be run at compile-time and returns an error. 

> This isn't a tidy design for CTFE (but it probably allows a simpler implementation of it). 

> Is this going to be a problem in programs that use CTFE a lot? It looks even worse than Python dynamic typing, this seems dynamic compilation :-)

I think that sort of thing will be pretty rare, once CTFE is fully 
implemented. But tt would not be very difficult to implement a check for 
that.
Still, CTFE functions are always going to fail when they divide by zero, 
exceed array bounds, etc.