Thread overview
Special Code String for mixins
Mar 15
Inquie
Mar 15
Inquie
Mar 15
Inquie
March 15
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)








March 15
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.


March 15
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.

March 15
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);
March 15
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).

March 15
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.

March 15
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.
March 15
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.
March 15
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.