Another way to do CTFE

Tofu Ninja via Digitalmars-d digitalmars-d at puremagic.com
Tue Jun 17 13:21:34 PDT 2014


On Tuesday, 17 June 2014 at 19:41:59 UTC, Ary Borenszweig wrote:
> CTFE is really nice but has its limitations: you can't do 
> anything you want, and since it's interpreted it requires an 
> interpreter and it's generally slow. Nimrod does the same 
> thing, and now they are implementing a VM to run the 
> interpreted code faster. Is this really the way to go?
>
> In our language we are thinking about allowing code generation 
> at compile time but in a different way. The idea is, at compile 
> time, to compile and execute another program that would 
> generate the code that would be mixed into the current program. 
> This program could receive the execution context as arguments, 
> along with any AST nodes that are passed to the program.
>
> So right now in D you can do ctRegex:
>
> auto ctr = ctRegex!(`^.*/([^/]+)/?$`);
>
> I don't know what the syntax could be, but the idea is to have 
> a file ct_regex.d. This file would receive the string as an 
> argument and must generate the code that would be mixed in the 
> program. Since this program is a program (compiled and 
> executed), it has no limits on what it can do. Then you would 
> do something like this:
>
> mixin(compile_time_execute("ct_regex.d", `^.*/([^/]+)/?$`));
>
> The compiler could be smart and cache the executable so that 
> anytime it has to expand it it just needs to invoke it (skip 
> the compile phase).
>
> What do you think?
>
> I know, I know. The first answer I'll get is: "Oh, no! But that 
> way I could download a program, compile it and suddenly all my 
> files are gone". My reply is: If you downloaded and compiled 
> that program, weren't you going to execute it afterwards? At 
> that point the program could do something harmful, so what's 
> the difference?. You must either way check the source code to 
> see that something fishy isn't happening there.
>
> Just as a reference that something like this is possible, in 
> our language you can already do this:
>
> build_date = {{ system("date").stringify }}
> puts build_date
>
> That generates a program that has the build date embedded in 
> it. We can also get the git hash of a repo and stick it into 
> the executable without an additional Makefile or some build 
> process. "system" is our first step towards doing this 
> compile-time things. The next thing would be do do:
>
> ct_regex = {{ run("ct_regex", "^.*/([^/]+)/?$") }}

I had a similar idea a while ago. The only difference was that
instead of compiling and running some d file at compile time,
mine was simply run some pre-compiled executable at compile time
and return the output as a string(similar to string imports). I
expressed similar use cases as you mentioned, replace extremely
slow ctfe, but it didn't seem to catch on. Every one screamed
that it was a security risk and it died there.

-tofu


More information about the Digitalmars-d mailing list