Ref counting for CTFE?

[Steven Schveighoffer via Digitalmars-d]

On Thu, 29 May 2014 12:53:54 -0400, Dylan Knutson <tcdknutson at gmail.com>  
wrote:

> I'm not well acquainted with how the compiler works internally, or how  
> CTFE is implemented. But it seems like a full-blown D interpreter with  
> eval functionality is needed. Lots of scripting language interpreters  
> exist out there, and they all get relatively decent performance and  
> memory footprints (or at least much better than what DMD can get when  
> performing CTFE).
>
> Is there anything so radically different in D than these other  
> languages, that prevents the implementation of a run-of-the-mill VM to  
> eval D code? It just seems strange to me that it's such a problem when  
> this is basically solved by all scripting languages. And I'm really not  
> trying to downplay the difficulty in implementing CTFE in D, but rather  
> just figure out why it's so hard to implement in comparison.

The compilation speed of D is touted continually as a very important  
"feature".

Realistically, as long as you have the memory to sustain it, you will  
NEVER beat the current implementation because it never deallocates  
anything. By definition, deallocating some things will add more length to  
the compile time.

I think as long as the slowdown doesn't result in an order of magnitude  
difference, we should be fine. Nobody will complain about 5 second compile  
times vs. 4 second ones (well, mostly nobody). People will definitely  
notice and complain about 15 second compile times vs 4 second ones.

It remains to be seen how any of this would perform. It is an idea to  
think about, and I didn't realize someone already had considered it. The  
thing I like about it, is that the environment is a restrictive one where  
we can try ref counting + GC out, without adversely affecting actual  
running D code. Once the compiler is finished, there are no traces of the  
CTFE interpreted heap. See the recent threads about the issues with adding  
ref counting to the language.

And when I say "we", I mean people other than me who can write compiler  
code :) So there is that... (ducks)

-Steve