digitalmars.D - Compile-time features (was: generative programming and debugging)
- Gor Gyolchanyan (40/92) Oct 19 2011 What I'd basically like is the __func__ "macro" and be able to obtain
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) =3D=3D "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 nospam.com> wrote:On 19.10.2011 12:50, Gor Gyolchanyan wrote:e,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 releas=which gives a substantially better call stack trace when an error occurs. Please suggest further improvements.isOn Wed, Oct 19, 2011 at 2:32 PM, Timon Gehr<timon.gehr gmx.ch> =A0wrote: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 =oo,I don't know how it could really do that. I mean, what if at the end of f=not immediately obvious which function generated the incorrect code. import std.stdio, std.conv; string X(string file=3D__FILE__, int line=3D__LINE__){ =A0 =A0 return "// "~file~"("~to!string(line)~")\n"; } string foo(){ =A0 =A0string r; =A0 =A0foreach(i;0..3) r~=3Dq{writeln("hello world");}~X(); =A0 =A0foreach(i;0..3) r~=3Dq{writekn("hello world");}~X(); // whoops =A0 =A0return r; } void main(){ =A0 =A0pragma(msg, foo()); =A0 =A0mixin(foo()); } It would be kinda nice if the compiler pointed directly to the source location that generated the incorrect code.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!
Oct 19 2011