What's the use case for D's compile time evaluation

Question

I integrated this feature in my favoriate language OCaml, I know that this is the sexy feature in D, but what's the use case for compile time evaluation except some optimizations? The more the better, the geeker the better :-)

Answer 1

Optimization is, of course, a big use case. Things like ctRegex perform better than their runtime compiled regex equivalent (generally). Parser generators are also interesting (see Pegged) and going to be receiving more and more attention. People are just beginning to tap in to what can be done.

You could do something like mixin(import_c("header.h")) to parse and build a D interface file for arbitrary C headers (you would, of course, need to write a parser for C in D to do this).

Extremely fast string formatting can be done since a format string (e.g., "%0.2f") is typically known at compile time. You can read the format string and only generate the code necessary to format, stripping out all sorts of unnecessary sections.

vibe.d actually supports compile time templating. The template file (Jade/HAML based) can contain D code. It reads it and generates a custom block of D code (think of it like "" ~ title ~ "..."). I don't believe the author has done benchmarks but it should be incredibly fast.

You essentially get the benefit of specialized hand-optimized code while staying high level. It's hard to answer your question because we just don't know what it'll be used for. It reminds me of C++ templates. The designers of them did not anticipate the advanced metaprogramming techniques it enabled.

Answer 2

Some suggestions:

• How about parsing a PEG grammar, assembling a PEG parser, and then using said parser, all at compile time? Here's the Pegged project.
• Construction of large static lookup tables.
• Generating optimal native code for a regular expression: std.regex.StaticRegex
• Implementing protobufs from a definition file.
• Many functions, if their inputs are known at compile time, can be evaluated then instead of at runtime--all without changing the implementation of the function.

Answer 3

When used with mixin, it can provide a great deal of flexibility.

Consider the following example:

template StructFromFile(string fileName){
    string makeStructMembersCode(string[] s){
        if(0==s.length){
            return null;
        }
        string memberName=s[0].strip;
        return q{
            string }~memberName~q{;
            }~makeStructMembersCode(s[1..$]);
    }
    struct StructFromFile{
        mixin(makeStructMembersCode(import(fileName).splitLines));
    }
}

This creates a struct that it's members are the lines of a text file. Now, imagine you have a table in a database, and you want to create a D struct to store rows from that table. You can write a shell script that reads that table's schema and write it to a file, and then use StructFromFile to automatically create a struct that can hold that table's rows. If you change the schema, you don't have the change the struct's code. You do, however, have to change any code that relies on the old schema - but that's a good thing, since it turns run-time bugs to compile errors.

Ofcourse, you can also use this method to add getter+setter properties, and to use it for XML DTD's and webservices.

Answer 4

Here's the geekest application of compile time evaluation I can think of: Write a compiler for your own programming language in form of a function string f(string code) which takes source code of your programming language as an argument and spits out D code. Then write something like

mixin( f( import("my_code_file") ) );

into your main.d file. This way you can abuse the D compiler and its backend to produce an executable for you. If you want, you can write a shell script (or something like unto it) which creates the main.d file and runs the D compiler over it. This way you get half a compiler for your language. At least you don't need to care about the backend. ;)

Appart from that, I have read about a compile time raytracer in D.