Compile time executable calling?

[Timothee Cour]

On Fri, Jul 12, 2013 at 6:14 PM, H. S. Teoh <hsteoh at quickfur.ath.cx> 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 <hsteoh at 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 at 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 ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130712/3f1edd43/attachment.html>