On Fri, Jul 12, 2013 at 6:14 PM, H. S. Teoh <span dir="ltr"><<a href="mailto:hsteoh@quickfur.ath.cx" target="_blank">hsteoh@quickfur.ath.cx</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Fri, Jul 12, 2013 at 05:39:45PM -0700, Timothee Cour wrote:<br>
> On Fri, Jul 12, 2013 at 5:10 PM, H. S. Teoh <<a href="mailto:hsteoh@quickfur.ath.cx">hsteoh@quickfur.ath.cx</a>> wrote:<br>
><br>
> > On Fri, Jul 12, 2013 at 05:00:29PM -0700, Timothee Cour wrote:<br>
> > > On Fri, Jul 12, 2013 at 4:51 PM, H. S. Teoh <<a href="mailto:hsteoh@quickfur.ath.cx">hsteoh@quickfur.ath.cx</a>><br>
> > wrote:<br>
> > ><br>
> > > > On Sat, Jul 13, 2013 at 12:51:03AM +0200, Tofu Ninja wrote:<br>
> > > > > On Friday, 12 July 2013 at 22:36:22 UTC, Peter Alexander wrote:<br>
> > > > > >On Friday, 12 July 2013 at 20:42:50 UTC, Tofu Ninja wrote:<br>
> > > > > >>So I had an idea recently, wouldn't it be cool to have the<br>
> > > > > >>ability to call an executable at compile time and capture its<br>
> > > > > >>output.<br>
> > > > > ><br>
> > > > > >How long until D compilers are able to read mail? :-)<br>
> > > ><br>
> > > > Zawinski's law of software envelopment:<br>
> > > ><br>
> > > > Every program attempts to expand until it can read mail.<br>
> > > > Those programs which cannot so expand are replaced by<br>
> > > > ones which can.<br>
> > ><br>
> > ><br>
> > > forget about reading mail, we currently don't even have hello world! (we<br>
> > > have pragma(msg) but no ctfewriteln, which pragma(msg) can't do)<br>
> ><br>
> > Why should the compiler turn into a hello world program?<br>
> ><br>
><br>
><br>
> For logging / debugging purposes, we often need to be able to print at<br>
> compile time some variables, but ctfeWriteln doesn't even work. And<br>
> again, pragma(msg) can't replace it.<br>
<br>
</div>This is a bug / limitation in CTFE, not a justification for invoking<br>
arbitrary programs from the compiler.<br></blockquote><div><br></div><div>there would be so many other things to fix (what if I want to access environment variables? or know whether a program / library is available?). </div>
<div>Whereas simply allowing CTFE exec unleashes arbitrarily complex use cases. The choice would be up to the user to make use of it or not.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
[...]<br>
<div class="im">> > > We don't need yet another build system if we have "exec" available<br>
> > > at CT.<br>
> ><br>
> > That doesn't replace a proper build system.<br>
><br>
><br>
> I wrote a D based makefile-like tool in D (which uses direct acyclic<br>
> graph to find compilation order). It's much cleaner in D for obvious<br>
> reasons.<br>
<br>
</div>I'm interested. Is the code on github?</blockquote><div><br></div><div>Not yet, code isn't very presentable at the moment but API is easy to use; user can mix both pure D and a makefile-like DSL syntax, so it makes simple things simple and complex things possible. It's DRY (nothing has to be repeated twice, which makes maintenance easy). I can push it to github if there's interest, but my point is that doing such things in D is easier than one might think.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> > What if your external program itself is a D program that needs to be<br>
> > compiled first?<br>
><br>
><br>
> call exec("dmd mydeps.d"); (or exec("make -all") or the D based makefile)<br>
<br>
</div>So basically you're saying DMD should be expanded into a D shell?<br></blockquote><div><br></div><div>No I never intended that. the call to exec("dmd...") would be a regular statement in a regular D file to be compiled. All I'm suggesting is making at least some of the functions in std.process CTFE-able.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
[...]<br>
<div class="im">> > So we're no longer talking about the D compiler, but about the D<br>
> > operating system. The real "DOS". :-P Which, mind you, would be a good<br>
> > thing IMO, but I think it's a bit of a stretch from where we are<br>
> > currently.<br>
> ><br>
><br>
> No, all it requires in terms of dmd modification is CTFE exec.<br>
> The user can use it to do complex stuff if he so wishes.<br>
><br>
> CTFE already runs very complex program (involving std.algorithm and<br>
> whatnot), so there's already a justification for running complex<br>
> programs during CTFE. Allowing that one simple function will enable<br>
> many more things.<br>
<br>
</div>In the old days, somebody wrote a 1-line universal C program that could<br>
do literally *anything*. All you have to do is to specify, in C syntax,<br>
what you want the program to do. The program's source code is:<br>
<br>
#include "/dev/tty"<br>
<br>
:-) (Sadly, this no longer works on modern systems.)<br>
<br>
Seriously, though, I think adding an exec function is total overkill for<br>
working around CTFE limitations. If that's what we're trying to solve,<br>
we should be looking at how to improve CTFE, not adding a nuclear<br>
warhead to dmd.<br></blockquote><div><br></div><div>I disagree. From the compiler implementation perspective, it's very easy (only requires making some of std.process CTFE-able), yet unleashes lots of potential use cases. Versus what you're suggesting which is to provide implementation for each individual CTFE limitation one at a time.</div>
<div><br></div><div>Being lazy is good :-)</div><div><br></div><div>A similar argument could be made for runtime: if we didn't have std.process, we'd have to reimplement or wrap "in D" all missing features.</div>
<div>But thanks to std.process I can easily add many missing D functions, eg for readLink:</div><div>----</div><div><div>string realPath(string file){</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>import std.process;</div>
<div><span class="Apple-tab-span" style="white-space:pre"> </span>return runPython(`import os; a=os.path.realpath(`~file.escapeShellFileName~`); print(a);`);</div><div>}</div></div><div><div>string runPython(string code){</div>
<div><span class="Apple-tab-span" style="white-space:pre"> </span>import std.process;</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>string command=`python -c `~code.escapeShellFileName;</div><div>
<span class="Apple-tab-span" style="white-space:pre"> </span>return command.executeShell.outputThrows;</div><div>}</div></div><div><div>----</div><div><br></div><div>bam, that was easy. </div><div><br></div><div>I see no point in arbitrarily impose restrictions on future use cases.</div>
<div><br></div><div></div></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> > > Let's put it another way: if I or someone else made a pull request<br>
> > > for CTFE "exec", would it have a chance of being accepted?<br>
> ><br>
> > I'm not one to decide, you have to convince Walter.<br>
> ><br>
> > And I'm not saying this idea is good or bad, I'm just saying that<br>
> > you can already do such things without compiler support.<br>
><br>
><br>
> we can't even print variables during CTFE. Using a build system to do<br>
> that is way overkill.<br>
<br>
</div>If that's the root problem, then we should fix/improve CTFE. I'm not<br>
convinced that this should be grounds for adding an exec function to<br>
dmd. It seems to be complete overkill just for working around CTFE<br>
limitations.<br>
<br>
But maybe Walter has a different opinion about this. :)<br></blockquote><div><br></div><div>ping, Walter ?</div><div><br></div><div> </div></div>