Compile time executable calling?

Peter Alexander peter.alexander.au at gmail.com
Mon Jul 15 09:48:09 PDT 2013


On Monday, 15 July 2013 at 15:05:39 UTC, Tofu Ninja wrote:
> On Monday, 15 July 2013 at 13:26:13 UTC, Don wrote:
>> Don't underestimate the fact that the compiler is a 
>> deterministic program at present. When compiled with the same 
>> flags, on the same set of source files, the results should 
>> always be the same. It's a classic filter program.
>>
>> input -> compiler -> output
>>
>> Losing that purity is a HUGE thing to give up.
>
> Ehh... to say its deterministic is kinda a stretch, for one, 
> compiling on different systems could result in different output 
> with the ability to version different sections of code. Also as 
> has been mentioned before, string imports already make the same 
> kind of break in purity.

If you want to be technical then yes, the purity takes the 
operating system as an input.

String imports don't break purity, they just add an input.

By allowing arbitrary code execution, you essentially require the 
whole state of the host machine as an input.

> If the programmer wants to use it then they also should be well 
> aware of the consequences of such a decision, which can be 
> considered on a case by case basis.
>
> We should be as flexible as possible and leave the decision up 
> to the programmer. We shouldn't restrict a feature based on a 
> fictional idea of purity or vague worry of feature bloat(as 
> others have mentioned) especially in a case like this where the 
> implementation is fairly simple and the use cases are immense.

No, this is a bad attitude to have. If you add a feature that is 
easy to misuse then it WILL be misused. Just looks at macros in C.

Any program that uses compile time executable calling will almost 
certainly become non-portable. This is not a good thing.


More information about the Digitalmars-d mailing list