Compile time function execution...

[Andrei Alexandrescu (See Website For Email)]

Dave wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> Walter Bright wrote:
>>> janderson wrote:
>>>> Walter Bright wrote:
>>>>> Right now, the compiler will fail if the compile time execution 
>>>>> results in infinite recursion or an infinite loop. I'll have to 
>>>>> figure out some way to eventually deal with this.
>>>>
>>>> Maybe you could allow the user to specify stack size and maximum 
>>>> iteration per loop/recursion function to the compiler as flags (with 
>>>> some defaults).   This way the user can up the size if they really 
>>>> need it.  This would make it a platform thing.  That way a D 
>>>> compiler could still be made for less powerful systems.
>>>
>>> Whether you tell it to fail at a smaller limit, or it fails by itself 
>>> at a smaller limit, doesn't make any difference as to whether it runs 
>>> on a less powerful system or not <g>.
>>>
>>> The C standard has these "minimum translation limits" for all kinds 
>>> of things - number of lines, chars in a string, expression nesting 
>>> level, etc. It's all kind of bogus, hearkening back to primitive 
>>> compilers that actually used fixed array sizes internally (Brand X, 
>>> who-shall-not-be-named, was notorious for exceeding internal table 
>>> limits, much to the delight of Zortech's sales staff). The right way 
>>> to build a compiler is it either runs out of stack or memory, and 
>>> that's the only limit.
>>>
>>> If your system is too primitive to run the compiler, you use a cross 
>>> compiler running on a more powerful machine.
>>>
>>> I have thought of just putting a timer in the interpreter - if it 
>>> runs for more than a minute, assume things have gone terribly awry 
>>> and quit with a message.
>>
>> That could be achieved with a watchdog process without changing the 
>> compiler, and it's more flexible.
>>
>> I think you just let the compiler go and crunch at it. Since you 
>> esentially have partial evaluation anyway, the execution process can 
>> be seen as extended to compile time. If you have a non-terminating 
>> program, that non-termination can be naturally manifest itself during 
>> compilation=partial evaluation.
>>
> 
> Completely agree, otherwise it contradicts your "right way to build a 
> compiler" statement except with time as the metric instead of memory. 
> Imagine the frustration of someone who has legitimate code and the 
> compiler always craps out half-way through a looong makefile, or worse 
> only sometimes craps out depending on machine load.

Yes, memory watching would be great. It is easy to write a script that 
watches dmd's memory and time consumed, and kills it past some 
configurable threshold.

> I think the best solution is to list out any compile-time execution with 
> the '-v' switch. That way if someone runs into this, they can throw -v 
> and find out where it's happening.

Sounds great.

Andrei