OT: Re: DConf Hackathon Ideas

[via Digitalmars-d]

On Friday, 28 April 2017 at 10:09:32 UTC, Moritz Maxeiner wrote:
> On Friday, 28 April 2017 at 09:52:29 UTC, Petar Kirov 
> [ZombineDev] wrote:
>>
>> AST introspection - given a function definition (!= 
>> declaration, i.e. the body is available) f, the expression 
>> __traits(ast, f) should return an instance of FuncDeclaration 
>> (https://github.com/dlang/dmd/blob/197ff0fd84b7b101f47458ab06e5b6f95959941e/src/ddmd/astnull.d#L151) with all of its members filled. The class-es used to represent the AST should be plain old data types (i.e. should contain no functionality). The AST as produced by the parser should be returned, without any semantic analysis (which can modify it). No backwards compatibility guarantees should be made about __traits(ast, f) at least for a couple of years.
>>
>
> This sounds interesting, but could you expand on what this 
> enables/improves compared to CTFE+mixins?

CTFE and mixins are building blocks, needed to for my idea to 
actually useful.
Currently if you want to introspect a piece of code (function 
body) at compile time,
you need to duplicate the code in a string and then pass this 
string to a
CTFE-able D parser. As you can imagine, even with Stefan's new 
CTFE engine,
this would be orders of magnitude slower than just reusing the 
work that parser
inside the compiler *has already done* anyway. This makes such 
code introspection
infeasible for large projects. Strings (at least until mixined)
can contain uncompilable source (though lexically valid, in the 
case of q{}),
further complicating the matter. Additionally, the fact that you 
need to
keep the source code and the strings in sync is just stupid, 
violating DRY
at a whole new level.

In addition to AST introspection, AST transformation should be as 
easy as:

mixin template profileFunctionStatements(alias func, string 
newFunctionName)
{
     enum funcAst = __traits(ast, func);
     enum newAst = insertProfiling(funcAst, newFunctionName);
     mixin(newAst.toString());

     // a further optimization would be AST mixins, which
     // could directly be used by the compiler, instead of
     // first converting the AST to string and then
     // parsing it after mixing:
     mixin(newAst);
}

void main()
{
     int local = 42;

     void fun(int[] arr)
     {
         import std.conv : text;
         import std.file : remove, write;
         arr[] += local;
         string s = text(arr);
         "delete-me.txt".write(s);
     }

     mixin profileFunctionStatements!(print, `funInstrumented`);

     import std.array : array;
     import std.range : iota;
     funInstrumented(10000.iota.array);
}

Output:
{  arr[] += local;  } took 0.002 miliseconds to execute.
{  string s = text(arr);  } took 1.8052 miliseconds to execute.
{ "delete-me.txt".write(s); } took 7.746 miliseconds to execute.

Where funInstrumented could be generated to something like this:

void funInstrumented(int[] arr)
{
     import std.datetime : __Sw = StopWatch, __to = to; // 
generated
     import std.stdio : __wfln = writefln; // generated
     import std.conv : text;
     import std.file : remove, write;

     __Sw __sw; // generated

     __sw.start(); // generated
     arr[] += local;
     __sw.stop(); // generated
     __wfln("{ %s } took %s miliseconds to execute.",
         q{ arr[] += local; },
         __sw.peek().__to!("msecs", double)); // generated

     __sw.start(); // generated
     string s = text(arr);
     __sw.stop(); // generated
     __wfln("{ %s } took %s miliseconds to execute.",
         q{ string s = text(arr); },
         __sw.peek().__to!("msecs", double)); // generated

     __sw.start(); // generated
     "delete-me.txt".write(s);
      __sw.stop(); // generated
     __wfln("{%s} took %s miliseconds to execute.",
         q{ "delete-me.txt".write(s); },
         __sw.peek().__to!("msecs", double)); // generated
}

Other applications include:
* compiling/transpiling D functions to targets
like JS, SPIR-V, WebAssembly, etc. using CTFE.
* CTFE-driven code diagnostics (linting)
* Adding semantic to user defined attributes:
   E.g. @asyncSafe attribute for use in libraries like vibe.d that 
allows calling only
   functions marked as @asyncSafe from @asyncSafe code. That way 
libraries can
   introduce *and enforce* correct use of UDAs without any need 
for language changes.
* ...