Compile-time features (was: generative programming and debugging)

[Gor Gyolchanyan]

What I'd basically like is the __func__ "macro" and be able to obtain
the __FILE__ and __LINE__ of the call site of current function without
needing to explicitly specify those parameters (at least because this
way I can't have variadic parameters).
Also, since we're talking about compile-time features,
It would be awesome to have more complete compile-time reflection.

What i suggest is to move __traits to Phobos:
Provide a way to obtain a compile-time string containing the source
code of specified symbol:

void hw() { writeln("Hello, world!"); }
assert(__source(hw) == "void hw() { writeln("Hello, world!"); }");

Then, __traits would become a template in object.d module, which
obtains the source code (as shown above), parses it as necessary and
returns the required results.
This would be the ultimate compile-time reflection mechanism, heavily
supported by Phobos in the form of ready-to-use templates, which do
the dirty work of parsing the source code.
With this feature, combined with string mixins, the phrase "you can't
do that in D" will disappear from the lexicon of this community.
Using this mega-powerful feature directly is difficult and tedious,
since you'll need to parse D code, which makes this feature even
better, since you should resort to this feature only when absolutely
nothing else can be used instead.

Here are some compile-time features i really miss currently.
* Be able to obtain all meta-types of the members, retrieved via
__traits with derivedMembers and allMembers in a uniform manner:
    * Is it a type definition, a function definition, a variable
definition or a template definition.
* Be able to query all template parameter sets for a template with
which the template was instantiated (essentially, get all instances of
the specified template).
    * this would allow to easily register necessary information for
run-time use.
* And most importantly, be able to obtain the complete source code of
the specified symbol. This would allow to parse out the rest of
required information for the ultimate compile-time reflection.

On Wed, Oct 19, 2011 at 4:46 PM, Don <nospam at nospam.com> wrote:
> On 19.10.2011 12:50, Gor Gyolchanyan wrote:
>>
>> good point. I'll need to generate comments for that code, that contain
>> information about the place, where the code was generated.
>>
>> There are 2 things I'd really like to have:
>> 1. Be able to obtain the name (possibly an alias) of a function on the
>> call stack on the given depth.
>> 2. Be able to obtain file and line of a function on the call stack on
>> the given depth.
>> This would be awesome for generating very convenient debug info.
>
> I've made a couple of improvements to the CTFE engine for the next release,
> which gives a substantially better call stack trace when an error occurs.
> Please suggest further improvements.
>
>
>> On Wed, Oct 19, 2011 at 2:32 PM, Timon Gehr<timon.gehr at gmx.ch>  wrote:
>>>
>>> On 10/19/2011 11:07 AM, Gor Gyolchanyan wrote:
>>>>
>>>> Do anybody know a good way to (statically) debug a generated code?
>>>> Currently it takes lots of effort to determine the place, where the
>>>> code is being incorrectly generated.
>>>
>>> pragma(msg, foo()); // debug
>>> mixin(foo());
>>>
>>> You can additionally use something in the lines of the following if it is
>>> not immediately obvious which function generated the incorrect code.
>>>
>>> import std.stdio, std.conv;
>>>
>>> string X(string file=__FILE__, int line=__LINE__){
>>>     return "// "~file~"("~to!string(line)~")\n";
>>> }
>>>
>>> string foo(){
>>>    string r;
>>>    foreach(i;0..3) r~=q{writeln("hello world");}~X();
>>>    foreach(i;0..3) r~=q{writekn("hello world");}~X(); // whoops
>>>    return r;
>>> }
>>>
>>> void main(){
>>>    pragma(msg, foo());
>>>    mixin(foo());
>>> }
>>>
>>>
>>> It would be kinda nice if the compiler pointed directly to the source
>>> location that generated the incorrect code.
>
> I don't know how it could really do that. I mean, what if at the end of foo,
> you looped over 'r' and changed every 'k' to 'l', and every 'l' to 'k'?
> Then the first line would be the one with the error!
>
>
>
>