On Fri, Jul 12, 2013 at 6:14 PM, H. S. Teoh <[email protected]> wrote:
> On Fri, Jul 12, 2013 at 05:39:45PM -0700, Timothee Cour wrote: > > On Fri, Jul 12, 2013 at 5:10 PM, H. S. Teoh <[email protected]> > wrote: > > > > > On Fri, Jul 12, 2013 at 05:00:29PM -0700, Timothee Cour wrote: > > > > On Fri, Jul 12, 2013 at 4:51 PM, H. S. Teoh <[email protected]> > > > wrote: > > > > > > > > > On Sat, Jul 13, 2013 at 12:51:03AM +0200, Tofu Ninja wrote: > > > > > > On Friday, 12 July 2013 at 22:36:22 UTC, Peter Alexander 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. > > > > > > > > > > > > > >How long until D compilers are able to read mail? :-) > > > > > > > > > > Zawinski's law of software envelopment: > > > > > > > > > > Every program attempts to expand until it can read mail. > > > > > Those programs which cannot so expand are replaced by > > > > > ones which can. > > > > > > > > > > > > forget about reading mail, we currently don't even have hello world! > (we > > > > have pragma(msg) but no ctfewriteln, which pragma(msg) can't do) > > > > > > Why should the compiler turn into a hello world program? > > > > > > > > > For logging / debugging purposes, we often need to be able to print at > > compile time some variables, but ctfeWriteln doesn't even work. And > > again, pragma(msg) can't replace it. > > This is a bug / limitation in CTFE, not a justification for invoking > arbitrary programs from the compiler. > 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?). 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. [...] > > > > We don't need yet another build system if we have "exec" available > > > > at CT. > > > > > > That doesn't replace a proper build system. > > > > > > I wrote a D based makefile-like tool in D (which uses direct acyclic > > graph to find compilation order). It's much cleaner in D for obvious > > reasons. > > I'm interested. Is the code on github? 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. > > What if your external program itself is a D program that needs to be > > > compiled first? > > > > > > call exec("dmd mydeps.d"); (or exec("make -all") or the D based makefile) > > So basically you're saying DMD should be expanded into a D shell? > 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. > [...] > > > So we're no longer talking about the D compiler, but about the D > > > operating system. The real "DOS". :-P Which, mind you, would be a good > > > thing IMO, but I think it's a bit of a stretch from where we are > > > currently. > > > > > > > No, all it requires in terms of dmd modification is CTFE exec. > > The user can use it to do complex stuff if he so wishes. > > > > CTFE already runs very complex program (involving std.algorithm and > > whatnot), so there's already a justification for running complex > > programs during CTFE. Allowing that one simple function will enable > > many more things. > > In the old days, somebody wrote a 1-line universal C program that could > do literally *anything*. All you have to do is to specify, in C syntax, > what you want the program to do. The program's source code is: > > #include "/dev/tty" > > :-) (Sadly, this no longer works on modern systems.) > > Seriously, though, I think adding an exec function is total overkill for > working around CTFE limitations. If that's what we're trying to solve, > we should be looking at how to improve CTFE, not adding a nuclear > warhead to dmd. > 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. Being lazy is good :-) 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. But thanks to std.process I can easily add many missing D functions, eg for readLink: ---- string realPath(string file){ import std.process; return runPython(`import os; a=os.path.realpath(`~file.escapeShellFileName~`); print(a);`); } string runPython(string code){ import std.process; string command=`python -c `~code.escapeShellFileName; return command.executeShell.outputThrows; } ---- bam, that was easy. I see no point in arbitrarily impose restrictions on future use cases. > > > > Let's put it another way: if I or someone else made a pull request > > > > for CTFE "exec", would it have a chance of being accepted? > > > > > > I'm not one to decide, you have to convince Walter. > > > > > > And I'm not saying this idea is good or bad, I'm just saying that > > > you can already do such things without compiler support. > > > > > > we can't even print variables during CTFE. Using a build system to do > > that is way overkill. > > If that's the root problem, then we should fix/improve CTFE. I'm not > convinced that this should be grounds for adding an exec function to > dmd. It seems to be complete overkill just for working around CTFE > limitations. > > But maybe Walter has a different opinion about this. :) > ping, Walter ?
