1) Appender does not work at compile time.
2) I assume that interp is mainly used for code generation.
    So, I think the cost of implementing and the purpose are incongruous.

Kenji

2010/11/2 Andrei Alexandrescu <andrei at erdani.com>:
> One more thing - for efficiency, instead of using to!string, I suggest you use formattedWrite with "%s" as format string and an appender as writer.
>
> Andrei
>
> On 11/2/10 5:40 AM, kenji hara wrote:
>>
>> Thanks for your response, Andrei.
>>
>> I applied improvements that suggested from you.
>> - Identifier expression currently does not require braces.
>> - Interpolation expression is converted to string implicitly (with
>> std.conv.to!string(...)).
>>
>> It is still not renamed to 'inter' in github, but I would to do it when committing to Phobos.
>>
>> Kenji Hara
>>
>> 2010/11/2 Andrei Alexandrescu<andrei at erdani.com>:
>>>
>>> This is great. It's funny I was thinking the same this morning before
>>> having
>>> looked over this message.
>>>
>>> As expansion using $xxx is called interpolation in Perl and probably
>>> other
>>> scripting languages I suggest we call the facility "inter".
>>>
>>> We can use it with writeln, which I think will be quite popular:
>>>
>>> int a = 2;
>>> string b = "hello";
>>> writeln(mixin(inter!"I told you $a times: $str!"));
>>>
>>> As shown above, I also suggest that we don't require {} when the
>>> expression
>>> is an identifier.
>>>
>>> A debatable language change would allow us to eliminate "mixin", as it
>>> has
>>> been discussed in the newsgroup. A simpler and less dangerous change
>>> would
>>> be to make the paren optional:
>>>
>>> writeln(mixin inter!"I told you $a times: $str!");
>>>
>>>
>>>
>>> Andrei
>>>
>>> On 10/31/10 10:50 AM, kenji hara wrote:
>>>>
>>>> I wrote a trivial utility template for generating code string. This provides some easiness and viewability of metaprogramming. (This is currently used in my adaptTo.)
>>>>
>>>> http://github.com/9rnsr/scrap/blob/master/expand/expand.d
>>>>
>>>> Sample:
>>>> ----
>>>> template GenFunc(string name)
>>>> {
>>>> ? mixin(
>>>> ? ? mixin(expand!q{
>>>> ? ? ? int ${name}(){ return 10; }
>>>> ? ? }));
>>>> ? // result of expand! is:
>>>> ? // ? q{`int ` ~ name ~ `(){ return 10; }`}
>>>> }
>>>> mixin GenFunc!("test"); ? // generates function "test" returns int
>>>> unittest{
>>>> ? assert(test() == 10);
>>>> }
>>>> ----
>>>>
>>>> expand!q{ codes... } parses D code string, and expands ${ expr } for embedding expr that is expression evaluated as string in compile-time.
>>>>
>>>> do you think?
>>>>
>>>> Kenji
>>>> _______________________________________________
>>>> phobos mailing list
>>>> phobos at puremagic.com
>>>> http://lists.puremagic.com/mailman/listinfo/phobos
>>>
>>> _______________________________________________
>>> phobos mailing list
>>> phobos at puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/phobos
>>>
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>

Indeed, sorry.

I think expand is fine with me too.

Simen - I think a good motivation can be found in Terence Parr's StringTemplate documentation, for example:

http://www.antlr.org/wiki/display/ST/Introduction

Andrei

On 11/2/10 11:05 AM, kenji hara wrote:
> 1) Appender does not work at compile time.
> 2) I assume that interp is mainly used for code generation.
>      So, I think the cost of implementing and the purpose are incongruous.
>
> Kenji
>
> 2010/11/2 Andrei Alexandrescu<andrei at erdani.com>:
>> One more thing - for efficiency, instead of using to!string, I suggest you use formattedWrite with "%s" as format string and an appender as writer.
>>
>> Andrei
>>
>> On 11/2/10 5:40 AM, kenji hara wrote:
>>>
>>> Thanks for your response, Andrei.
>>>
>>> I applied improvements that suggested from you.
>>> - Identifier expression currently does not require braces.
>>> - Interpolation expression is converted to string implicitly (with
>>> std.conv.to!string(...)).
>>>
>>> It is still not renamed to 'inter' in github, but I would to do it when committing to Phobos.
>>>
>>> Kenji Hara
>>>
>>> 2010/11/2 Andrei Alexandrescu<andrei at erdani.com>:
>>>>
>>>> This is great. It's funny I was thinking the same this morning before
>>>> having
>>>> looked over this message.
>>>>
>>>> As expansion using $xxx is called interpolation in Perl and probably
>>>> other
>>>> scripting languages I suggest we call the facility "inter".
>>>>
>>>> We can use it with writeln, which I think will be quite popular:
>>>>
>>>> int a = 2;
>>>> string b = "hello";
>>>> writeln(mixin(inter!"I told you $a times: $str!"));
>>>>
>>>> As shown above, I also suggest that we don't require {} when the
>>>> expression
>>>> is an identifier.
>>>>
>>>> A debatable language change would allow us to eliminate "mixin", as it
>>>> has
>>>> been discussed in the newsgroup. A simpler and less dangerous change
>>>> would
>>>> be to make the paren optional:
>>>>
>>>> writeln(mixin inter!"I told you $a times: $str!");
>>>>
>>>>
>>>>
>>>> Andrei
>>>>
>>>> On 10/31/10 10:50 AM, kenji hara wrote:
>>>>>
>>>>> I wrote a trivial utility template for generating code string. This provides some easiness and viewability of metaprogramming. (This is currently used in my adaptTo.)
>>>>>
>>>>> http://github.com/9rnsr/scrap/blob/master/expand/expand.d
>>>>>
>>>>> Sample:
>>>>> ----
>>>>> template GenFunc(string name)
>>>>> {
>>>>>    mixin(
>>>>>      mixin(expand!q{
>>>>>        int ${name}(){ return 10; }
>>>>>      }));
>>>>>    // result of expand! is:
>>>>>    //   q{`int ` ~ name ~ `(){ return 10; }`}
>>>>> }
>>>>> mixin GenFunc!("test");   // generates function "test" returns int
>>>>> unittest{
>>>>>    assert(test() == 10);
>>>>> }
>>>>> ----
>>>>>
>>>>> expand!q{ codes... } parses D code string, and expands ${ expr } for embedding expr that is expression evaluated as string in compile-time.
>>>>>
>>>>> do you think?
>>>>>
>>>>> Kenji
>>>>> _______________________________________________
>>>>> phobos mailing list
>>>>> phobos at puremagic.com
>>>>> http://lists.puremagic.com/mailman/listinfo/phobos
>>>>
>>>> _______________________________________________
>>>> phobos mailing list
>>>> phobos at puremagic.com
>>>> http://lists.puremagic.com/mailman/listinfo/phobos
>>>>
>>> _______________________________________________
>>> phobos mailing list
>>> phobos at puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/phobos
>>
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
>>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

My first motivation is more easiness of writing meta-programming code. For formatting output, I usually use writefln.

Quoted-string is very usuful, but interpolating variable is very difficult.
----
string count = "10";
enum code = q{ enum msg = "I call you } ~ count ~ q{ times"; }
// I want to generate q{ enum msg = "I call you 10 times"; }, but can't.
----
With expand!, I can write code generating very easy.

Last, adaptTo contains following code:
----
// generates function definition
template generateFun(string n)
{
  enum generateFun = mixin(expand!q{
    mixin DeclareFunction!(
      CoTypes[${n}],  // covariant
      NameOf!(TgtFuns[${n}]),
      "return source." ~ NameOf!(TgtFuns[${n}]) ~ "(args);"
    );
  });
}
// mixin all generated function definitions here
mixin mixinAll!(
  staticMap!(
    generateFun,
    staticMap!(StringOf, staticIota!(0,
      TgtFuns.length))));
----
If expand! does not exist, it would be terribly ugly.

Kenji

2010/11/2 Robert Jacques <sandford at jhu.edu>:
> On Tue, 02 Nov 2010 10:03:23 -0400, Andrei Alexandrescu <andrei at erdani.com> wrote:
>
>> Thanks, Kenji. All - ideas for a better name? "interp"? Full "interpolate"? Leave it as "expand"?
>>
>> Andrei
>
> Well, "interpolate" and "interp" have mathematical connotations to me, so vote-- for those. Note that functionality of this seems very similar to both format and text:
>
> enum int a = 10;
> enum string op = "+";
> static assert(mixin(expand!q{ ${a*2} ${op} 2 }) == q{ 20 + 2 });
> vs.
> static assert(Format!(" %s %s 2 ",a*2,op)) == q{ 20 + 2 });
> vs.
> static assert(text(" ",a*2," ",op," 2 ") == q{ 20 + 2 };
>
> So maybe some variant of format would be appropriate: MixinFormat, mFormat, mText, FormatInPlace, etc, though these all seem clunky. MixinFormat would make a lot of sense if you could declare a template that's always a mixin, and could simply write MixinFormat!q{ ${a*2} ${op} 2 } instead of mixin(MixinFormat!q{ ${a*2} ${op} 2 }). As this syntax comes from perl, we could use that as a prefix: perlFormat / pFormat / perlText / pText.
>
> Also, am I missing something with regard to the use cases of expand/inter?
> All the examples given in the documentation seem to be better served by
> either text or Format.
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>

On Tue, Nov 2, 2010 at 6:47 PM, kenji hara <k.hara.pg at gmail.com> wrote:
> I like some short name on clear meaning.
>
> I googled "variable expansion" and "interpolation|interp" with some
> language names.
> There was no significant difference in result.
>
> (I'm not a native English speaker. Please read follows with a grain of salt.)
>
> "interp" may remind us "interpolation(=variable expansion)",
> "interpolation(math)", and "interpreter".
> On the other hand, "expand" is more general word than "interp".
> So, I think that "interp" will be more better .
>
> Kenji
>
> 2010/11/2 Andrei Alexandrescu <andrei at erdani.com>:
>> Thanks, Kenji. All - ideas for a better name? "interp"? Full "interpolate"? Leave it as "expand"?
>>
>> Andrei
>>
>> On 11/2/10 5:40 AM, kenji hara wrote:
>>>
>>> Thanks for your response, Andrei.
>>>
>>> I applied improvements that suggested from you.
>>> - Identifier expression currently does not require braces.
>>> - Interpolation expression is converted to string implicitly (with
>>> std.conv.to!string(...)).
>>>
>>> It is still not renamed to 'inter' in github, but I would to do it when committing to Phobos.
>>>
>>> Kenji Hara
>>>
>>> 2010/11/2 Andrei Alexandrescu<andrei at erdani.com>:
>>>>
>>>> This is great. It's funny I was thinking the same this morning before
>>>> having
>>>> looked over this message.
>>>>
>>>> As expansion using $xxx is called interpolation in Perl and probably
>>>> other
>>>> scripting languages I suggest we call the facility "inter".
>>>>
>>>> We can use it with writeln, which I think will be quite popular:
>>>>
>>>> int a = 2;
>>>> string b = "hello";
>>>> writeln(mixin(inter!"I told you $a times: $str!"));
>>>>
>>>> As shown above, I also suggest that we don't require {} when the
>>>> expression
>>>> is an identifier.
>>>>
>>>> A debatable language change would allow us to eliminate "mixin", as it
>>>> has
>>>> been discussed in the newsgroup. A simpler and less dangerous change
>>>> would
>>>> be to make the paren optional:
>>>>
>>>> writeln(mixin inter!"I told you $a times: $str!");
>>>>
>>>>
>>>>
>>>> Andrei
>>>>
>>>> On 10/31/10 10:50 AM, kenji hara wrote:
>>>>>
>>>>> I wrote a trivial utility template for generating code string. This provides some easiness and viewability of metaprogramming. (This is currently used in my adaptTo.)
>>>>>
>>>>> http://github.com/9rnsr/scrap/blob/master/expand/expand.d
>>>>>
>>>>> Sample:
>>>>> ----
>>>>> template GenFunc(string name)
>>>>> {
>>>>> ? mixin(
>>>>> ? ? mixin(expand!q{
>>>>> ? ? ? int ${name}(){ return 10; }
>>>>> ? ? }));
>>>>> ? // result of expand! is:
>>>>> ? // ? q{`int ` ~ name ~ `(){ return 10; }`}
>>>>> }
>>>>> mixin GenFunc!("test"); ? // generates function "test" returns int
>>>>> unittest{
>>>>> ? assert(test() == 10);
>>>>> }
>>>>> ----
>>>>>
>>>>> expand!q{ codes... } parses D code string, and expands ${ expr } for embedding expr that is expression evaluated as string in compile-time.
>>>>>
>>>>> do you think?
>>>>>
>>>>> Kenji
>>>>> _______________________________________________
>>>>> phobos mailing list
>>>>> phobos at puremagic.com
>>>>> http://lists.puremagic.com/mailman/listinfo/phobos
>>>>
>>>> _______________________________________________
>>>> phobos mailing list
>>>> phobos at puremagic.com
>>>> http://lists.puremagic.com/mailman/listinfo/phobos
>>>>
>>> _______________________________________________
>>> phobos mailing list
>>> phobos at puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/phobos
>>
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
>>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>

I like expand.

$variable name is good, but it would be more powerful to use
{expression} syntax, e.g. expand!("1 + 2 = {1 + 2}");
I also think that expand could return not a string but rather a tuple
of strings and evaluated expression values.

Currently

int result = 3;
auto expanded = expand!("1 + 2 = ${result}");

evaluates to "`1 + 2 = ` ~ .std.conv.to!string(result) ~ ``". Wouldn't it be better to evaluate to "tuple(`1 + 2 = `, result)" instead? I think this would both simplify an "expand", improve performance and provide additional functionality. expandString could be used get the current behavior.

Compare: writeln(mixin(expand!("1 + 2 = ${result}"))); vs
writeln(expand!("1 + 2 = ${result}"));

The second one is shorter (doesn't use mixin) and faster (doesn't do
unnecessary concatenations).

On Tue, 02 Nov 2010 12:32:54 -0400, kenji hara <k.hara.pg at gmail.com> wrote:

> My first motivation is more easiness of writing meta-programming code.
> For formatting output, I usually use writefln.
> Quoted-string is very usuful, but interpolating variable is very
> difficult.
> ----
> string count = "10";
> enum code = q{ enum msg = "I call you } ~ count ~ q{ times"; }
> // I want to generate q{ enum msg = "I call you 10 times"; }, but can't.

The main issue is that q{} string respect D syntax, so the } inside the "" is treated as text, not a terminator. There's lots of ways around this:

enum code = text(q{ enum msg = "I call you "}, count, q{" times"} );
enum code = text(` enum msg = "I call you `, count, ` times;` );
enum code = ` enum msg = "I call you ` ~ count ~ ` times;`
enum code = q{ enum msg = "I call you "} ~ count ~ q{" times"; }

> ----
> With expand!, I can write code generating very easy.
> Last, adaptTo contains following code:
> ----
> // generates function definition
> template generateFun(string n)
> {
>   enum generateFun = mixin(expand!q{
>     mixin DeclareFunction!(
>       CoTypes[${n}],  // covariant
>       NameOf!(TgtFuns[${n}]),
>       "return source." ~ NameOf!(TgtFuns[${n}]) ~ "(args);"
>     );
>   });
> }
> // mixin all generated function definitions here
> mixin mixinAll!(
>   staticMap!(
>     generateFun,
>     staticMap!(StringOf, staticIota!(0,
>       TgtFuns.length))));
> ----
> If expand! does not exist, it would be terribly ugly.
> Kenji

Really?
template generateFun(string n)
{
   enum generateFun = mixin(text(q{
     mixin DeclareFunction!(
       CoTypes[},n,q{],  // covariant
       NameOf!(TgtFuns[},n,q{]),
       "return source." ~ NameOf!(TgtFuns[},n,q{]) ~ "(args);"
     );
   });
}

I admit ${n} is slightly better than },n,q{, but it's by no means ugly. (And using `` instead of q{} makes it better: `,n,`)

> enum code = text(q{ enum msg = "I call you "}, count, q{" times"} );
> enum code = text(` enum msg = "I call you `, count, ` times;` );
> enum code = ` enum msg = "I call you ` ~ count ~ ` times;`
> enum code = q{ enum msg = "I call you "} ~ count ~ q{" times"; }

1st and 4th does not generate intended code string, but generates invalid one.
expand! generates 3rd code automatically cooperation with mixin.
(2nd is ... the code currently others want to generate for run-time
performance?)

> I admit ${n} is slightly better than },n,q{, but it's by no means ugly. (And using `` instead of q{} makes it better: `,n,`)

The advantage of expand! is that escapes string quotations and
concatenates correctly while keeping readability of our meta-code
well.
(In above 3rd, you escape q{} to `` and interpolate "count" *manually*.)

Kenji

2010/11/3 Robert Jacques <sandford at jhu.edu>:
> On Tue, 02 Nov 2010 12:32:54 -0400, kenji hara <k.hara.pg at gmail.com> wrote:
>
>> My first motivation is more easiness of writing meta-programming code.
>> For formatting output, I usually use writefln.
>> Quoted-string is very usuful, but interpolating variable is very
>> difficult.
>> ----
>> string count = "10";
>> enum code = q{ enum msg = "I call you } ~ count ~ q{ times"; }
>> // I want to generate q{ enum msg = "I call you 10 times"; }, but can't.
>
> The main issue is that q{} string respect D syntax, so the } inside the "" is treated as text, not a terminator. There's lots of ways around this:
>
> enum code = text(q{ enum msg = "I call you "}, count, q{" times"} );
> enum code = text(` enum msg = "I call you `, count, ` times;` );
> enum code = ` enum msg = "I call you ` ~ count ~ ` times;`
> enum code = q{ enum msg = "I call you "} ~ count ~ q{" times"; }
>
>> ----
>> With expand!, I can write code generating very easy.
>> Last, adaptTo contains following code:
>> ----
>> // generates function definition
>> template generateFun(string n)
>> {
>> ?enum generateFun = mixin(expand!q{
>> ? ?mixin DeclareFunction!(
>> ? ? ?CoTypes[${n}], ?// covariant
>> ? ? ?NameOf!(TgtFuns[${n}]),
>> ? ? ?"return source." ~ NameOf!(TgtFuns[${n}]) ~ "(args);"
>> ? ?);
>> ?});
>> }
>> // mixin all generated function definitions here
>> mixin mixinAll!(
>> ?staticMap!(
>> ? ?generateFun,
>> ? ?staticMap!(StringOf, staticIota!(0,
>> ? ? ?TgtFuns.length))));
>> ----
>> If expand! does not exist, it would be terribly ugly.
>> Kenji
>
> Really?
> template generateFun(string n)
> {
> ?enum generateFun = mixin(text(q{
> ? ?mixin DeclareFunction!(
> ? ? ?CoTypes[},n,q{], ?// covariant
> ? ? ?NameOf!(TgtFuns[},n,q{]),
> ? ? ?"return source." ~ NameOf!(TgtFuns[},n,q{]) ~ "(args);"
> ? ?);
> ?});
> }
>
> I admit ${n} is slightly better than },n,q{, but it's by no means ugly. (And
> using `` instead of q{} makes it better: `,n,`)
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>

On Tue, 02 Nov 2010 14:27:28 -0400, kenji hara <k.hara.pg at gmail.com> wrote:

>> enum code = text(q{ enum msg = "I call you "}, count, q{" times"} );
>> enum code = text(` enum msg = "I call you `, count, ` times;` );
>> enum code = ` enum msg = "I call you ` ~ count ~ ` times;`
>> enum code = q{ enum msg = "I call you "} ~ count ~ q{" times"; }
>
> 1st and 4th does not generate intended code string, but generates
> invalid one.
> expand! generates 3rd code automatically cooperation with mixin.
> (2nd is ... the code currently others want to generate for run-time
> performance?)

Opps. Sorry, I tested 2 & 3, but forgot to test 1 & 2. I also seemed to have forgotten a " after times in 2 & 3.

Also, what do you mean by: (2nd is ... the code currently others want to generate for run-time performance?)

>> I admit ${n} is slightly better than },n,q{, but it's by no means ugly.
>> (And
>> using `` instead of q{} makes it better: `,n,`)
>
> The advantage of expand! is that escapes string quotations and
> concatenates correctly while keeping readability of our meta-code
> well.
> (In above 3rd, you escape q{} to `` and interpolate "count" *manually*.)

Yes, manually escaping and concatenating, in all but the trivial cases, is really annoying. But my main point was that text is both CTFE-able and lets you cleanly do everything expand does naturally. Expand is more complex to use, isn't self-documenting (i.e. you have to remember to use a mixin), is mostly redundant and increases the radius of comprehension of phobos. However, it does allow you to escape a token strings inside a nested string in a nice in-lined way. So far, the examples don't seem to provide a strong argument for yet another text formater beyond text and Format. Also, if I recall correctly the plan is to get a large portion of both phobos and D CTFE compatible, which would eventually eliminate the need for the current metastrings.

On 11/2/10 2:34 PM, Robert Jacques wrote:
> Yes, manually escaping and concatenating, in all but the trivial cases, is really annoying. But my main point was that text is both CTFE-able and lets you cleanly do everything expand does naturally. Expand is more complex to use, isn't self-documenting (i.e. you have to remember to use a mixin), is mostly redundant and increases the radius of comprehension of phobos. However, it does allow you to escape a token strings inside a nested string in a nice in-lined way. So far, the examples don't seem to provide a strong argument for yet another text formater beyond text and Format. Also, if I recall correctly the plan is to get a large portion of both phobos and D CTFE compatible, which would eventually eliminate the need for the current metastrings.

expand's style is instantly recognizable to anyone coming from Perl, PHP, and a plethora of shell languages.

Andrei

The points of text vs expand are:
- text is comma separated formatting, expand is inlined formatting.
- text is general formatting function, expand is mostly useful in
compile-time, and specialized D code formatting for code generation.
- editor hilighting issue - my editor does not color q{}, so
generating code are colored with normal syntax hilighting. If I use
text and its formatting, code readability will be wrong. I don't like
it.

> Also, if I
> recall correctly the plan is to get a large portion of both phobos and D
> CTFE compatible, which would eventually eliminate the need for the current
> metastrings.
Almost agreed. I think std.metastrings.toStringNow should be
deprecated, and replaced std.conv.to.
The purpose of std.metastrings I think is that has useful utilities
often specialized for code generation.
Expand is just right.

Kenji

2010/11/3 Robert Jacques <sandford at jhu.edu>:
> On Tue, 02 Nov 2010 14:27:28 -0400, kenji hara <k.hara.pg at gmail.com> wrote:
>
>>> enum code = text(q{ enum msg = "I call you "}, count, q{" times"} );
>>> enum code = text(` enum msg = "I call you `, count, ` times;` );
>>> enum code = ` enum msg = "I call you ` ~ count ~ ` times;`
>>> enum code = q{ enum msg = "I call you "} ~ count ~ q{" times"; }
>>
>> 1st and 4th does not generate intended code string, but generates invalid
>> one.
>> expand! generates 3rd code automatically cooperation with mixin.
>> (2nd is ... the code currently others want to generate for run-time
>> performance?)
>
> Opps. Sorry, I tested 2 & 3, but forgot to test 1 & 2. I also seemed to have forgotten a " after times in 2 & 3.
>
> Also, what do you mean by: (2nd is ... the code currently others want to generate for run-time performance?)
>
>>> I admit ${n} is slightly better than },n,q{, but it's by no means ugly.
>>> (And
>>> using `` instead of q{} makes it better: `,n,`)
>>
>> The advantage of expand! is that escapes string quotations and
>> concatenates correctly while keeping readability of our meta-code
>> well.
>> (In above 3rd, you escape q{} to `` and interpolate "count" *manually*.)
>
> Yes, manually escaping and concatenating, in all but the trivial cases, is really annoying. But my main point was that text is both CTFE-able and lets you cleanly do everything expand does naturally. Expand is more complex to use, isn't self-documenting (i.e. you have to remember to use a mixin), is mostly redundant and increases the radius of comprehension of phobos. However, it does allow you to escape a token strings inside a nested string in a nice in-lined way. So far, the examples don't seem to provide a strong argument for yet another text formater beyond text and Format. Also, if I recall correctly the plan is to get a large portion of both phobos and D CTFE compatible, which would eventually eliminate the need for the current metastrings.
>
>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>

And, I do not recommend following use of expand:
writeline(mixin(expand!"take $n times."));

The probrem is:
- expand concatenates string by ~ operators, it is may cost than using
appender(text, formatWrite, writefln...)

I will remove ddoc example from github code.

Kenji

2010/11/3 kenji hara <k.hara.pg at gmail.com>:
> The points of text vs expand are:
> - text is comma separated formatting, expand is inlined formatting.
> - text is general formatting function, expand is mostly useful in
> compile-time, and specialized D code formatting for code generation.
> - editor hilighting issue - my editor does not color q{}, so
> generating code are colored with normal syntax hilighting. If I use
> text and its formatting, code readability will be wrong. I don't like
> it.
>
>> Also, if I
>> recall correctly the plan is to get a large portion of both phobos and D
>> CTFE compatible, which would eventually eliminate the need for the current
>> metastrings.
> Almost agreed. I think std.metastrings.toStringNow should be
> deprecated, and replaced std.conv.to.
> The purpose of std.metastrings I think is that has useful utilities
> often specialized for code generation.
> Expand is just right.
>
> Kenji
>
> 2010/11/3 Robert Jacques <sandford at jhu.edu>:
>> On Tue, 02 Nov 2010 14:27:28 -0400, kenji hara <k.hara.pg at gmail.com> wrote:
>>
>>>> enum code = text(q{ enum msg = "I call you "}, count, q{" times"} );
>>>> enum code = text(` enum msg = "I call you `, count, ` times;` );
>>>> enum code = ` enum msg = "I call you ` ~ count ~ ` times;`
>>>> enum code = q{ enum msg = "I call you "} ~ count ~ q{" times"; }
>>>
>>> 1st and 4th does not generate intended code string, but generates invalid
>>> one.
>>> expand! generates 3rd code automatically cooperation with mixin.
>>> (2nd is ... the code currently others want to generate for run-time
>>> performance?)
>>
>> Opps. Sorry, I tested 2 & 3, but forgot to test 1 & 2. I also seemed to have forgotten a " after times in 2 & 3.
>>
>> Also, what do you mean by: (2nd is ... the code currently others want to generate for run-time performance?)
>>
>>>> I admit ${n} is slightly better than },n,q{, but it's by no means ugly.
>>>> (And
>>>> using `` instead of q{} makes it better: `,n,`)
>>>
>>> The advantage of expand! is that escapes string quotations and
>>> concatenates correctly while keeping readability of our meta-code
>>> well.
>>> (In above 3rd, you escape q{} to `` and interpolate "count" *manually*.)
>>
>> Yes, manually escaping and concatenating, in all but the trivial cases, is really annoying. But my main point was that text is both CTFE-able and lets you cleanly do everything expand does naturally. Expand is more complex to use, isn't self-documenting (i.e. you have to remember to use a mixin), is mostly redundant and increases the radius of comprehension of phobos. However, it does allow you to escape a token strings inside a nested string in a nice in-lined way. So far, the examples don't seem to provide a strong argument for yet another text formater beyond text and Format. Also, if I recall correctly the plan is to get a large portion of both phobos and D CTFE compatible, which would eventually eliminate the need for the current metastrings.
>>
>>
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
>>
>