New syntax for string mixins

[Graham St Jack]

I have done a fair bit of mixin coding using recursive templates 
(inspired by std.typecons). It was an amazing taste of what you can do 
in D, and I am delighted with the result - HEAPS of boiler-plate coding 
vanished before my eyes. However, the template code is virtually 
impossible to understand.

What you are suggesting here seems to be a way to dramatically reduce 
the complexity of code that generates source-code and mixes it in. I 
think something like that is needed before this mind-bogglingly powerful 
feature of D can realise its potential.

There is of course the worry that it could get so easy that everyone 
starts doing it, and we have (relatively) impenetrable code everywhere 
instead of just deep in the bowels of framework libraries.


On 14/12/10 07:07, Jacob Carlborg wrote:
> This is an idea I've been thinking of for a while, it's not a really 
> suggestion (at least not yet) I just wanted to here what people think 
> about it.
>
> If we take a step back and look at what string mixins actually do or 
> rather what they're used for, that would be: inserting a piece/block 
> of code where the mixin expression is used. If we then take a look at 
> how a block of code is represented in D (how you store it in variables 
> and how you pass it around). It's not as a string which is used by the 
> mixin expression, instead delegates are used to represent a block of 
> code in D that can be passed around. Therefore this is my idea:
>
> Add a new mixin operator "@" (1). When that operator is put in front 
> of a function call it would behave as a string mixin. The function 
> that is called needs to be CTFE and return a delegate or an array of 
> delegates:
>
> class Foo
> {
>     @get_set("int", "bar");
> }
>
> The above code would be the same as the following code:
>
> class Foo
> {
>     mixin(get_set("int", "bar"));
> }
>
> If we now move to the declaration of "get_set" this is how it could 
> look like:
>
> void delegate () get_set (string type, string name)
> {
>     return
>     {
>         @type _ at name;
>
>         @type @name ()
>         {
>             return _ at name;
>         }
>
>         @type @name (@type @name)
>         {
>             return _ at name = @name;
>         }
>     };
> }
>
> In the above code when "@" is used in the delegate literal it 
> basically behaves like string interpolation, so "@type" would be 
> replaced with the content of the "type" variable (2).
>
> When the "get_set" function is called with the mixin symbol the 
> content of the returned delegate is inserted where the call is made. 
> If the function returns an array of delegates then the array would be 
> unfolded and the content of all the delegates would be inserted.
>
>
>
> Taking it one step further:
>
> Allow the mixin syntax to be placed in front of most of the 
> declarations and drop the need for string literals, commas and 
> parentheses, basically allowing the following syntax:
>
> class Foo
> {
>     @get_set int bar;
> }
>
> Would be translated into this:
>
> class Foo
> {
>     @get_set!(int)("bar");
> }
>
> Maybe one could do something like this as well:
>
> @singleton class Foo
> {
>
> }
>
> void delegate () singleton (string name, void delegate () classBody)
> {
>     return { // a simple singleton implementation
>         class @name
>         {
>             static @name instance;
>
>             static this ()
>             {
>                 instance = new @name;
>             }
>
>             private this () {}
>
>             @classBody;
>         }
>     };
> }
>
> Above, in the last example, @classBody would insert the content of the 
> delegate, basically the class body.
>
> 1. I will use "@" in this example because I think it looks good but it 
> would probably conflict with @nothrow, @property and others.
>
> 2. I have no idea if this usage of the mixin symbol, "@", will 
> conflict with the first usage.
>


-- 
Graham St Jack