> P.S. Does expansion of types work? i.e. q{$int} == "int".

It does not, but can use ${int.stringof}.

Kenji

2010/11/4 Robert Jacques <sandford at jhu.edu>:
> On Wed, 03 Nov 2010 02:04:45 -0400, kenji hara <k.hara.pg at gmail.com> wrote:
>>
>> Paste my old code which creates tagged-union.
>> Is this a example of strong argument?
>
> Strong argument: no. Borderline argument: yes. Mainly it's ugly because it's an example from (I assume) a time before you knew strings could be multi-lined. Switch to using multi-line strings, and it cleans up rather nicely.
>
> P.S. Does expansion of types work? i.e. q{$int} == "int".
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>

> Personally, I consider comma separated formatting to be inlined, or at least inline style
OK, I call the kind of expand "Embedded Formatting" in this discussion, to avoid confusion.

I again want to emphasize with the Need of Embedded Formatting, with some code.
If you only use built-in string literals, you can't avoid escaping of
code string.
----
enum op = "+";
enum code = "a "~op~" b";
// use "" and manual escaping. It is same with r"" and ``.
enum code = mixin(expand!"a $op b");
// automatically escaping

// quoted string has problem with embedding...
enum code = q{
  struct A{
    enum str = "hello!";
    enum val = a }~op~{ b;  // invalid! can't embed correctly.
  }
};
enum code = "
  struct A{
    enum str = \"hello!\";  // manual escaping!
    enum val = a " ~ op ~ " b;
  }
";
enum code = mixin(expand!q{
  struct A{
    enum str = "hello!";    // automatically escaping
    enum val = a $op b;     // automatically embedding
  }
});  // and editor highlighting will mostly succeed.
----
I DO NOT want to think about escaping of code string!
In this regard, expand is very usuful.

Kenji

2010/11/3 Robert Jacques <sandford at jhu.edu>:
> On Tue, 02 Nov 2010 16:08:11 -0400, kenji hara <k.hara.pg at gmail.com> wrote:
>>
>> The points of text vs expand are:
>> - text is comma separated formatting, expand is inlined formatting.
>
> Personally, I consider comma separated formatting to be inlined, or at least inline style, but I understand your point.
>
>> - text is general formatting function, expand is mostly useful in compile-time, and specialized D code formatting for code generation.
>
> And text is both general and works at compile time.
>
>> - editor highlighting issue - my editor does not color q{}, so generating code are colored with normal syntax highlighting. If I use text and its formatting, code readability will be wrong. I don't like it.
>
> I think this is the biggest advantage of it. Well, that and familiarity to
> Perl, PHP, etc, users.
> But the amount/size of code inside these strings need to be pretty large
> before it gets really annoying. For me, your generateFun example (which is
> the only use of expand in interfaces.d) is a two liner, and is simply not
> big enough to start sweating about these issues to me. And most of my large
> mixins for me are generated dynamically; my need for expanding variables in
> long strings is pretty minimal. You wouldn't have/know of a good example of
> a long explicit string mixin requiring non-trivial expansion, would you?
>
> I recognize the benefits of expand, but I'm just concerned about introducing yet-another string formating routine, particularly one that looks low-yield in terms of power and is rather complex, into phobos.
>
> Part of this problem could be addressed with better documentation, which highlights the shell-like syntax and the differences between expand, text, Format and ~.
>
>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>

On Thu, 04 Nov 2010 01:04:46 -0400, kenji hara <k.hara.pg at gmail.com> wrote:
>> P.S. Does expansion of types work? i.e. q{$int} == "int".
>
> It does not, but can use ${int.stringof}.
>

Can I request that support for types be added? T.stringof is by far the most common escape in my mixin strings.

I supported your suggestion. https://github.com/9rnsr/scrap/blob/master/expand/expand.d

Now, ${Type} is expanded to Type.stringof.
see unittest in https://github.com/9rnsr/scrap/blob/master/expand/expand_utest.d

Kenji

2010/11/4 Robert Jacques <sandford at jhu.edu>:
> On Thu, 04 Nov 2010 01:04:46 -0400, kenji hara <k.hara.pg at gmail.com> wrote:
>>>
>>> P.S. Does expansion of types work? i.e. q{$int} == "int".
>>
>> It does not, but can use ${int.stringof}.
>>
>
> Can I request that support for types be added? T.stringof is by far the most
> common escape in my mixin strings.
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>

On Thu, 04 Nov 2010 02:06:37 -0400, kenji hara <k.hara.pg at gmail.com> wrote:

>> Personally, I consider comma separated formatting to be inlined, or at least inline style
> OK, I call the kind of expand "Embedded Formatting" in this discussion, to avoid confusion.
>
> I again want to emphasize with the Need of Embedded Formatting, with
> some code.
> If you only use built-in string literals, you can't avoid escaping of
> code string.
> ----
> enum op = "+";
> enum code = "a "~op~" b";
> // use "" and manual escaping. It is same with r"" and ``.
> enum code = mixin(expand!"a $op b");
> // automatically escaping
>
> // quoted string has problem with embedding...
> enum code = q{
>   struct A{
>     enum str = "hello!";
>     enum val = a }~op~{ b;  // invalid! can't embed correctly.
>   }
> };
> enum code = "
>   struct A{
>     enum str = \"hello!\";  // manual escaping!
>     enum val = a " ~ op ~ " b;
>   }
> ";
> enum code = mixin(expand!q{
>   struct A{
>     enum str = "hello!";    // automatically escaping
>     enum val = a $op b;     // automatically embedding
>   }
> });  // and editor highlighting will mostly succeed.
> ----
> I DO NOT want to think about escaping of code string!
> In this regard, expand is very usuful.
>
> Kenji

I just wanted to point out that D has 6 different types of Wysiwyg Strings in addition to standard escape based "" strings and the q{} token strings. i.e.

enum code = `
    struct A{
      enum str = "hello!";
      enum val = a `~op~` b;
   `;

Anyways, for me, $Type definitely makes expand a worthwhile addition to Phobos.

Thanks, Robert.
I think we reached consensus.

Kenji

2010/11/6 Robert Jacques <sandford at jhu.edu>:
> On Thu, 04 Nov 2010 02:06:37 -0400, kenji hara <k.hara.pg at gmail.com> wrote:
>
>>> Personally, I consider comma separated formatting to be inlined, or at least inline style
>>
>> OK, I call the kind of expand "Embedded Formatting" in this discussion, to avoid confusion.
>>
>> I again want to emphasize with the Need of Embedded Formatting, with some
>> code.
>> If you only use built-in string literals, you can't avoid escaping of
>> code string.
>> ----
>> enum op = "+";
>> enum code = "a "~op~" b";
>> // use "" and manual escaping. It is same with r"" and ``.
>> enum code = mixin(expand!"a $op b");
>> // automatically escaping
>>
>> // quoted string has problem with embedding...
>> enum code = q{
>> ?struct A{
>> ? ?enum str = "hello!";
>> ? ?enum val = a }~op~{ b; ?// invalid! can't embed correctly.
>> ?}
>> };
>> enum code = "
>> ?struct A{
>> ? ?enum str = \"hello!\"; ?// manual escaping!
>> ? ?enum val = a " ~ op ~ " b;
>> ?}
>> ";
>> enum code = mixin(expand!q{
>> ?struct A{
>> ? ?enum str = "hello!"; ? ?// automatically escaping
>> ? ?enum val = a $op b; ? ? // automatically embedding
>> ?}
>> }); ?// and editor highlighting will mostly succeed.
>> ----
>> I DO NOT want to think about escaping of code string!
>> In this regard, expand is very usuful.
>>
>> Kenji
>
> I just wanted to point out that D has 6 different types of Wysiwyg Strings in addition to standard escape based "" strings and the q{} token strings. i.e.
>
> enum code = `
> ? struct A{
> ? ? enum str = "hello!";
> ? ? enum val = a `~op~` b;
> ?`;
>
> Anyways, for me, $Type definitely makes expand a worthwhile addition to
> Phobos.
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>

Thanks, all.

Through the discussion, I supported following suggestions:
- Add non-string values formatting. (Andrei)
- Add type formatting. (Robert)
- Identifier expression can ommit braces. (Andrei)
- Add expandSplit makes comma separated code-sting.
  (i.e. expandSplit!"call $n times" generates q{`call `, n, ` times`}.)

And, I decided keeps expand's name.

If no other comments, I'd like to post to issue-tracker, and commit.

Kenji

2010/11/1 kenji hara <k.hara.pg at gmail.com>:
> 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
>

I'm just in the midst of working with a bunch of Python scripts, where the following pattern is used heavily:

     hql_init = '''
       CREATE TABLE IF NOT EXISTS
       {table_name}_xyz_{method}(id string, name string,
                                      id2 string, name2 string);
     '''.format(**locals())

Such a construct occurs in a random script I'm using at every 12 lines of code. It replaces {name} with the value of the variable called "name". The script would grow in size if a more awkward (e.g., manual or with printf) interpolation were used.

So here's what I think. Expansion like the above will be used much more heavily than expansion for the sake of code generation. The latter is an advanced activity that we should support, but not give it pole position.

So I suggest we call the more popular usage "expand" and the more advanced usage "expandCode". Or in general give the popular use a shorter, simpler name, and the advanced use a more explanatory, longer name.


Andrei

On 11/6/10 6:45 AM, kenji hara wrote:
> Thanks, all.
>
> Through the discussion, I supported following suggestions:
> - Add non-string values formatting. (Andrei)
> - Add type formatting. (Robert)
> - Identifier expression can ommit braces. (Andrei)
> - Add expandSplit makes comma separated code-sting.
>    (i.e. expandSplit!"call $n times" generates q{`call `, n, ` times`}.)
>
> And, I decided keeps expand's name.
>
> If no other comments, I'd like to post to issue-tracker, and commit.
>
> Kenji
>
> 2010/11/1 kenji hara<k.hara.pg at gmail.com>:
>> 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