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
next sibling 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 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
prev sibling next sibling parent "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
prev sibling next sibling parent "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

 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
prev sibling next sibling parent "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

 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
prev sibling 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

 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