www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Dlang code mixin output

reply "JS" <js.mdnq gmail.com> writes:
It would be nice to be able to have a precompilation step that 
produces a d output file that is the "mixed down" version with 
all the string mixins computed. This would allow one to look at 
the files, allow better code analysis/error messages, and 
intellisense and other things to be useful.

A simple compiler switch would do the trick to enable such a 
feature. *.dc files could be generated, or whatever, for each d 
file if it uses string mixins(I suppose template mixins could 
also be reduced).
Jul 31 2013
parent reply dennis luehring <dl.soluz gmx.net> writes:
Am 31.07.2013 14:09, schrieb JS:

 It would be nice to be able to have a precompilation step that
 produces a d output file that is the "mixed down" version with
 all the string mixins computed. This would allow one to look at
 the files, allow better code analysis/error messages, and
 intellisense and other things to be useful.

 A simple compiler switch would do the trick to enable such a
 feature. *.dc files could be generated, or whatever, for each d
 file if it uses string mixins(I suppose template mixins could
 also be reduced).


what about something that catches mixin results into a static 
compiletime strings

template GenStruct(string Name, string M1)
{
     const char[] GenStruct = "struct " ~ Name ~ "{ int " ~ M1 ~ "; }";
}

which generates:

struct Foo { int bar; }

catch_generated_output(my_mixin_output)
{
   mixin(GenStruct!("Foo", "bar"));
}

pragma(msg, my_mixin_output);

prints:

struct Foo { int bar; }
Jul 31 2013
next sibling parent dennis luehring <dl.soluz gmx.net> writes:
Am 31.07.2013 14:23, schrieb dennis luehring:

 Am 31.07.2013 14:09, schrieb JS:

 It would be nice to be able to have a precompilation step that
 produces a d output file that is the "mixed down" version with
 all the string mixins computed. This would allow one to look at
 the files, allow better code analysis/error messages, and
 intellisense and other things to be useful.

 A simple compiler switch would do the trick to enable such a
 feature. *.dc files could be generated, or whatever, for each d
 file if it uses string mixins(I suppose template mixins could
 also be reduced).


 what about something that catches mixin results into a static
 compiletime strings

 template GenStruct(string Name, string M1)
 {
       const char[] GenStruct = "struct " ~ Name ~ "{ int " ~ M1 ~ "; }";
 }

 which generates:

 struct Foo { int bar; }

 catch_generated_output(my_mixin_output)
 {
     mixin(GenStruct!("Foo", "bar"));
 }


or as an optional parameter for mixin(GenStruct!("Foo", "bar"), 
my_mixin_output)?
Jul 31 2013
prev sibling parent reply "JS" <js.mdnq gmail.com> writes:
On Wednesday, 31 July 2013 at 12:23:42 UTC, dennis luehring wrote:

 Am 31.07.2013 14:09, schrieb JS:

 It would be nice to be able to have a precompilation step that
 produces a d output file that is the "mixed down" version with
 all the string mixins computed. This would allow one to look at
 the files, allow better code analysis/error messages, and
 intellisense and other things to be useful.

 A simple compiler switch would do the trick to enable such a
 feature. *.dc files could be generated, or whatever, for each d
 file if it uses string mixins(I suppose template mixins could
 also be reduced).


 what about something that catches mixin results into a static 
 compiletime strings

 template GenStruct(string Name, string M1)
 {
     const char[] GenStruct = "struct " ~ Name ~ "{ int " ~ M1 ~ 
 "; }";
 }

 which generates:

 struct Foo { int bar; }

 catch_generated_output(my_mixin_output)
 {
   mixin(GenStruct!("Foo", "bar"));
 }

 pragma(msg, my_mixin_output);

 prints:

 struct Foo { int bar; }



I already do that... When you do that with nested templates it 
creates a huge mess... also errors are useless... as the point to 
the mixin string.

Simple examples are easy to come up with but don't demonstrate 
how useless they can be.
Jul 31 2013
parent reply dennis luehring <dl.soluz gmx.net> writes:
Am 31.07.2013 14:35, schrieb JS:

 On Wednesday, 31 July 2013 at 12:23:42 UTC, dennis luehring wrote:

 Am 31.07.2013 14:09, schrieb JS:

 It would be nice to be able to have a precompilation step that
 produces a d output file that is the "mixed down" version with
 all the string mixins computed. This would allow one to look at
 the files, allow better code analysis/error messages, and
 intellisense and other things to be useful.

 A simple compiler switch would do the trick to enable such a
 feature. *.dc files could be generated, or whatever, for each d
 file if it uses string mixins(I suppose template mixins could
 also be reduced).


 what about something that catches mixin results into a static
 compiletime strings

 template GenStruct(string Name, string M1)
 {
     const char[] GenStruct = "struct " ~ Name ~ "{ int " ~ M1 ~
 "; }";
 }

 which generates:

 struct Foo { int bar; }

 catch_generated_output(my_mixin_output)
 {
   mixin(GenStruct!("Foo", "bar"));
 }

 pragma(msg, my_mixin_output);

 prints:

 struct Foo { int bar; }



 I already do that...


it was just a proposal to have something between all (on commandline) 
and areas of the source


When you do that with nested templates it
 creates a huge mess... also errors are useless... as the point to
 the mixin string.


and what does a complete output help then better?
Jul 31 2013
parent reply "JS" <js.mdnq gmail.com> writes:
On Wednesday, 31 July 2013 at 13:19:46 UTC, dennis luehring wrote:

 Am 31.07.2013 14:35, schrieb JS:

 On Wednesday, 31 July 2013 at 12:23:42 UTC, dennis luehring 
 wrote:

 Am 31.07.2013 14:09, schrieb JS:

 It would be nice to be able to have a precompilation step 
 that
 produces a d output file that is the "mixed down" version 
 with
 all the string mixins computed. This would allow one to look 
 at
 the files, allow better code analysis/error messages, and
 intellisense and other things to be useful.

 A simple compiler switch would do the trick to enable such a
 feature. *.dc files could be generated, or whatever, for 
 each d
 file if it uses string mixins(I suppose template mixins could
 also be reduced).


 what about something that catches mixin results into a static
 compiletime strings

 template GenStruct(string Name, string M1)
 {
    const char[] GenStruct = "struct " ~ Name ~ "{ int " ~ M1 ~
 "; }";
 }

 which generates:

 struct Foo { int bar; }

 catch_generated_output(my_mixin_output)
 {
  mixin(GenStruct!("Foo", "bar"));
 }

 pragma(msg, my_mixin_output);

 prints:

 struct Foo { int bar; }



 I already do that...


 it was just a proposal to have something between all (on 
 commandline) and areas of the source


When you do that with nested templates it
 creates a huge mess... also errors are useless... as the


 point to

 the mixin string.


 and what does a complete output help then better?


Because it won't double up on pragmas.

If you nest templates using your method, which I do, then you 
will get multiple pragma outputs but you'll always only have one 
string mixin.

the processed output will be actual D code, not a bunch of pragma 
messages, which could be anything... even invalid D code if they 
are formatted that way.
Jul 31 2013
parent reply "Dicebot" <public dicebot.lv> writes:
On Wednesday, 31 July 2013 at 13:25:45 UTC, JS wrote:

 On Wednesday, 31 July 2013 at 13:19:46 UTC, dennis luehring

When you do that with nested templates it
 creates a huge mess... also errors are useless... as the


 point to

 the mixin string.






There is one idiom for debugging string mixin mess:
098: // pragma(msg, "mixin_id:");
099: // pragma(msg, generated_code);
100: #line 1 "mixin_id"
101: mixin(generated_code)
102: #line 103 __FILE__

Not very convenient, but enough to get the job done.

Sonke had nice idea to improve compiler by storing mixin id as 
part of filename an preserving line numbers as-is. Somewhat 
breaking change though.
Jul 31 2013
parent "JS" <js.mdnq gmail.com> writes:
On Wednesday, 31 July 2013 at 13:37:58 UTC, Dicebot wrote:

 On Wednesday, 31 July 2013 at 13:25:45 UTC, JS wrote:

 On Wednesday, 31 July 2013 at 13:19:46 UTC, dennis luehring

When you do that with nested templates it
 creates a huge mess... also errors are useless... as the


 point to

 the mixin string.






 There is one idiom for debugging string mixin mess:
 098: // pragma(msg, "mixin_id:");
 099: // pragma(msg, generated_code);
 100: #line 1 "mixin_id"
 101: mixin(generated_code)
 102: #line 103 __FILE__

 Not very convenient, but enough to get the job done.

 Sonke had nice idea to improve compiler by storing mixin id as 
 part of filename an preserving line numbers as-is. Somewhat 
 breaking change though.


I already have a method where I use level to store the nesting 
level, somewhat inconvenient but it allows me to not show any 
nested calls, just the top most template call...

But it doesn't help with intellisense, which thinks the 
structs/classes are empty because I generate everything with 
mixins(or almost everything at this point)... and is still hard 
to read. I'd rather be able to look at a complete D source to see 
if anything is out of place then look at a build console 
output(which may contain other information and doesn't show much 
context for the mixin).
Jul 31 2013