Compile time executable calling?

Tofu Ninja emmons0 at purdue.edu
Mon Jul 15 08:05:38 PDT 2013


On Monday, 15 July 2013 at 13:26:13 UTC, Don wrote:
> On Friday, 12 July 2013 at 20:42:50 UTC, Tofu Ninja wrote:
>> So I had an idea recently, wouldn't it be cool to have the 
>> ability to call an executable at compile time and capture its 
>> output. Something like the string imports but instead of 
>> opening and reading a text file, it run an executable, waits 
>> for it to finish, and grabs its output.
>>
>> It would get really cool if you could pass this executable 
>> some args and then mix in its out put into your own code. It 
>> could be used similarly to how CTFE are used but with out the 
>> overhead of trying to compile that function and what not and 
>> with out the limitations on what it can do.
>>
>> I could imagine all sorts of things that would be possible 
>> with this that is currently not.
>>
>> Not sure if this is something that could be implemented 
>> easily, but seems like something that could be done and 
>> something that would be really cool.
>
> I personally think it's a *horrible* idea. It's one of those 
> things which looks good in small cases but doesn't scale.
>
> 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 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.


More information about the Digitalmars-d mailing list