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 <hsteoh@quickfur.ath.cx> 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 <hsteoh@quickfur.ath.cx>
> > 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 ?