Reply to Don,

> 
> Some simple suggestions that would be major leaps forward in practical
> CTFE
> programming are:
> * gc at compile time, to stop the symbol table getting clogged up.

a re working of the symbol table system would help a lot. With nested template, I see no reasons that the data of the base template should be copied for every sub template. IMHO it should be carried by reference, alos the full name should never be built until it needs to be output. Lastly for large char[] terms in templates some form of slicing would cut down a lot on memory usage.

But what do I know, I've never written a full compiler. (just a lexer and a parser that won't compile because it's make DMD use to much ram :)

> * some version statement to detect if you are in CTFE. This would mean
> (a) you could create CTFE-able versions of code that uses (for
> example) asm
> at run-time; and far more importantly:
> (b) you could insert printf/writefln statements in the non-CTFE
> version, for
> assistance with debugging.

"Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message news:fk8i6s$4d$1@digitalmars.com...
> "Don Clugston" <dac@nospam.com.au> wrote in message news:fk8083$1cgb$1@digitalmars.com...
>
>> The real problem is that DMD doesn't seem to release CTFE memory properly.
>
> Now, if only we had a D frontend written in D, then this wouldn't be a problem.  Hmm...

How would this help?  From what I hear, Walter uses GC in his C++ code. 

On Tue, 18 Dec 2007 20:59:48 -0000, Bruce Adams <tortoise_74@yeah.who.co.uk> wrote:

> On Tue, 18 Dec 2007 15:53:27 -0000, Chad J <gamerChad@_spamIsBad_gmail.com> wrote:
>
>> Craig Black wrote:
>>> Currently, CTFE only supports a subset of the language, and it relies on the compiler acting as an interpreter, which is slow.  It just occured to me that if we could compile code to the heap, there would be no need for a CTFE interpreter.  CTFE code could be compiled to the heap and executed at full speed.  Further, all the features of D would be available at compile time.
>>>  Thoughts?
>>>  -Craig
>>
>> In response to concerns about cross-compilation and security concerns:
>>
>> Perhaps if D had a VM then we could do it?  At compile time, compile all of the CTFE code to bytecode, and interpret it.  The intrepreter would be compiled by whatever is compiling the compiler, so it should make cross-compiling easier.  Also, the VM and compiler can sandbox the CTFE code.  Bytecode interpretation is not native speed execution, but probably close enough, and this approach allows use of D's high level features.
>>
>> Only problem is, that would be a lot of work.  It involves writing a D backend for the bytecode, implementing security restrictions, and maybe even implementing the VM itself (if we can't find a ready-made one).
>
> It would complete the set to have a D front end to one a VM and to have a D compiler/front end in D.
> There are plenty of VMs out there that may or may not be suitable. Its just
> a different target. You'd need the front end to support cross compilation and it
> would be nice to have a command line switch like gcc does.
> I don't think I've seen a VM used as a target for gcc otherwise gdc would already
> have most of the functionality needed. Probably because p-code and gcc itself is so
> damned ugly inside. Someone should port it to D - and clean up the mess. It would
> make a good community project but I guess porting is less satisfying than re-inventing
> the wheel, especially when you have better constructs to work with from the start.
>
> With regard to VMs to target apart from the obvious JVM and .NET/Mono (makes my unix bones
> shudder in horror) there's also Neko which is supposedly designed to be ported to
> http://nekovm.org/. But there is no reason why you couldn't port to your favourite language (tm)'s
> VM with enough hard work. A D VM would be best able to exploit the language features but would
> be a hell of a lot of work (albeit highly rewarding).
>
> Bruce.

maybe a x86 emulator could be used instead... just a thought