www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Special Code String for mixins

reply Inquie <Inquie data1.com> writes:
I hate building code strings for string mixins as it's very ugly 
and seems like a complete hack.

How bout, instead, we have a special code string similar to a 
multiline string that allows us to represent valid D code. The 
compiler can then verify the string after compilation to make 
sure it is valid D code(since it ultimately is a compile time 
constant).

e.g.,

string s = "smile";
enum code1 =  #
void happyCode = "Makes me   s  ";
# 

enum code2 = code1 ~  #
int ImThisHappy =   s.length  ;
# 

mixin(code);

or

mixin(code.stringof); // possible to convert code string to a 
string and vice versa.


or whatever syntax one thinks is better. The point is that the 
code string is specified different and then is no longer 
ambiguous as a normal string. Compilers and IDE's can make more 
informed decisions.

There might be a much better way, but something should be done to 
clean up this area of D. It is a mess to have to use string 
building to create code. (it's amazingly powerful, but still a 
mess)
Mar 15
next sibling parent Inquie <Inquie data1.com> writes:
On Wednesday, 15 March 2017 at 13:50:28 UTC, Inquie wrote:
 I hate building code strings for string mixins as it's very 
 ugly and seems like a complete hack.

 How bout, instead, we have a special code string similar to a 
 multiline string that allows us to represent valid D code. The 
 compiler can then verify the string after compilation to make 
 sure it is valid D code(since it ultimately is a compile time 
 constant).

 e.g.,

 string s = "smile";
 enum code1 =  #
 void happyCode = "Makes me   s  ";
 # 

 enum code2 = code1 ~  #
 int ImThisHappy =   s.length  ;
 # 

 mixin(code);

 or

 mixin(code.stringof); // possible to convert code string to a 
 string and vice versa.


 or whatever syntax one thinks is better. The point is that the 
 code string is specified different and then is no longer 
 ambiguous as a normal string. Compilers and IDE's can make more 
 informed decisions.

 There might be a much better way, but something should be done 
 to clean up this area of D. It is a mess to have to use string 
 building to create code. (it's amazingly powerful, but still a 
 mess)
Alternatively, maybe one could specify code in a template like mechanism: template Code(string s) { void happyCode = "Makes me "~s; int ImThisHappy = s.length; } then turn the template in to a code string: Code("smile").stringof = `\tvoid happyCode = "Makes me "~s;\n\tint ImThisHappy = s.length;\n`; and so mixin(Code("smile").stringof); would do the same as the first example. The only problem I see is passing variables might become a mess... but still better than original.
Mar 15
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 15 March 2017 at 13:50:28 UTC, Inquie wrote:
 I hate building code strings for string mixins as it's very 
 ugly and seems like a complete hack.
Me too, that's why I avoid doing it. Check out my tips of the week here: http://arsdnet.net/this-week-in-d/sep-20.html and here: http://arsdnet.net/this-week-in-d/2016-feb-21.html for some ways I minimize them.
 How bout, instead, we have a special code string similar to a 
 multiline string that allows us to represent valid D code. The 
 compiler can then verify the string after compilation to make 
 sure it is valid D code(since it ultimately is a compile time 
 constant).
Are you familiar with D's `q{ ... }` literals? They are lexed though not parsed. enum code1 = q{ void happyCode = "Makes me s "; }; then you'd have to do the `.replace(" s ", whatever)` yourself on it though. They also do not allow unbalanced { }. It is typed as string btw, no special type, just like if you used regular quotes, just looks nicer at the definition.
Mar 15
parent Inquie <Inquie data1.com> writes:
On Wednesday, 15 March 2017 at 14:12:57 UTC, Adam D. Ruppe wrote:
 On Wednesday, 15 March 2017 at 13:50:28 UTC, Inquie wrote:
 I hate building code strings for string mixins as it's very 
 ugly and seems like a complete hack.
Me too, that's why I avoid doing it. Check out my tips of the week here: http://arsdnet.net/this-week-in-d/sep-20.html and here: http://arsdnet.net/this-week-in-d/2016-feb-21.html for some ways I minimize them.
 How bout, instead, we have a special code string similar to a 
 multiline string that allows us to represent valid D code. The 
 compiler can then verify the string after compilation to make 
 sure it is valid D code(since it ultimately is a compile time 
 constant).
Are you familiar with D's `q{ ... }` literals? They are lexed though not parsed. enum code1 = q{ void happyCode = "Makes me s "; }; then you'd have to do the `.replace(" s ", whatever)` yourself on it though. They also do not allow unbalanced { }. It is typed as string btw, no special type, just like if you used regular quotes, just looks nicer at the definition.
Visual D doesn't seem to do much. Maybe it is lexed but most of the code is a solid purple. Better than a normal string. I was hoping to get something parsed though to find based errors a CT in a meaningful way(line numbers, etc).
Mar 15
prev sibling next sibling parent Shachar Shemesh <shachar weka.io> writes:
On 15/03/17 15:50, Inquie wrote:
 I hate building code strings for string mixins as it's very ugly and
 seems like a complete hack.
What I usually do is use the q{} format. Vim does syntax highlighting on it: string code = q{ immutable int a = %s; }.format(something); ... mixin(code);
Mar 15
prev sibling next sibling parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 03/15/2017 09:50 AM, Inquie wrote:
 e.g.,

 string s = "smile";
 enum code1 =  #
 void happyCode = "Makes me   s  ";
 # 

 enum code2 = code1 ~  #
 int ImThisHappy =   s.length  ;
 # 

 mixin(code);
import scriptlike; // https://github.com/Abscissa/scriptlike string s = "smile"; // http://semitwist.com/scriptlike/scriptlike/core/interp.html enum code1 = mixin(interp!q{ void happyCode = "Makes me ${s}"; }); enum code2 = code1 ~ mixin(interp!q{ int ImThisHappy = ${s.length}; }); mixin(code2); Wish I could get rid of the need for "mixin(...)" in interp though.
Mar 15
parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Wednesday, 15 March 2017 at 15:39:38 UTC, Nick Sabalausky 
(Abscissa) wrote:
 On 03/15/2017 09:50 AM, Inquie wrote:
 e.g.,

 string s = "smile";
 enum code1 =  #
 void happyCode = "Makes me   s  ";
 # 

 enum code2 = code1 ~  #
 int ImThisHappy =   s.length  ;
 # 

 mixin(code);
import scriptlike; // https://github.com/Abscissa/scriptlike string s = "smile"; // http://semitwist.com/scriptlike/scriptlike/core/interp.html enum code1 = mixin(interp!q{ void happyCode = "Makes me ${s}"; }); enum code2 = code1 ~ mixin(interp!q{ int ImThisHappy = ${s.length}; }); mixin(code2); Wish I could get rid of the need for "mixin(...)" in interp though.
But you can. in interp you can evoke the function you generate however for that you need to pass s to it.
Mar 15
parent "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 03/15/2017 11:50 AM, Stefan Koch wrote:
 Wish I could get rid of the need for "mixin(...)" in interp though.
But you can. in interp you can evoke the function you generate however for that you need to pass s to it.
Thus reinventing writef and defeating the whole point of interpolated strings.
Mar 15
prev sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Wed, Mar 15, 2017 at 01:50:28PM +0000, Inquie via Digitalmars-d wrote:
 I hate building code strings for string mixins as it's very ugly and seems
 like a complete hack.
 
 How bout, instead, we have a special code string similar to a multiline
 string that allows us to represent valid D code. The compiler can then
 verify the string after compilation to make sure it is valid D code(since it
 ultimately is a compile time constant).
Have you looked up token string literals? enum myCode = q{ // This is actually a string that looks like code void func() { } // Of course it allows token sequences that aren't valid // D, but that's not important because mixin() will // complain if it's malformed. float void is double null {[ 0* }] }; T -- Not all rumours are as misleading as this one.
Mar 15