New syntax for string mixins

Jacob Carlborg doob at me.com
Thu Dec 16 14:49:56 PST 2010


On 2010-12-16 23:05, Jonathan M Davis wrote:
> On Thursday, December 16, 2010 11:28:03 Jacob Carlborg wrote:
>> On 2010-12-15 23:00, Nick Sabalausky wrote:
>>> "Jonathan M Davis"<jmdavisProg at gmx.com>   wrote in message
>>> news:mailman.1035.1292441722.21107.digitalmars-d at puremagic.com...
>>>
>>>> On Wednesday, December 15, 2010 11:27:47 Jacob Carlborg wrote:
>>>>> That was my idea as well, that
>>>>>
>>>>> @get_set("int", "bar");
>>>>>
>>>>> could be translated into
>>>>>
>>>>> mixin(get_set("int", "bar")); just like
>>>>>
>>>>> just like scope statements are translated into try/catch/finally.
>>>>
>>>> Honestly, I don't see much gain in using @ rather than mixin(). It's a
>>>> little
>>>> less typing, but that's it.
>>>
>>> It does seem like a small difference, just replacing "mixin" with "@" and
>>> removing one layer of parens. But I think that extra layer of parens,
>>> minor as it seems, makes a big difference in the readability (and
>>> "typeability") of mixin invocations. Those extra parens do get to be a
>>> real bother, major visual noise at least to my eyes.
>>
>> ^^ I completely agree.
>>
>>>> And it precludes stuff like mixin("lhs " ~ op ~ "
>>>> rhs") like happens all the time in overloaded operator functions.
>>>
>>> I don't see why these shouldn't work:
>>>
>>> @"int foo;";
>>> return @("lhs " ~ op ~ " rhs");
>>>
>>> At least with just the "@" part of the proposal. Maybe the delegate thing
>>> might make it tricker, I dunno.
>>
>> My idea was actually to get rid of the strings where the code to be
>> mixed in is defined and to have a better syntax where it's used.
>>
>> The delegates are just a way of passing a block of code around. If you
>> just use it in place then maybe one could do like this:
>>
>> @(int foo;);
>> return @(lhs@(op)rhs);
>
> I would have thought that template mixins would be the thing to use when you
> didn't want to deal with strings. string mixins are extremely powerful and
> flexible, and I'd really hate to lose them. And IIRC, Kenji Hara was working on a
> module to really help make dealing with complicated string mixins easier and
> less painful. Anything that you propose is going to have to have major benefits
> over the current string mixin situation for it to stand any chance of being
> accepted.
>
> - Jonathan M Davis

Template mixins and string mixins are used for different things. There's 
a lot of things that string mixins can do that template mixins can't. I 
have no intention what so ever to suggest something that isn't as 
powerful as string mixins, just a new syntax. If it turns out that a 
having a powerful syntax without strings isn't possibles than I'll guess 
we have to live with the strings.

Don't know if you read my first post put there I wrote that it wasn't a 
real suggestion (at least not yet) I just wanted the community's 
thoughts on the idea and see if we could turn it into something useful 
that could become a real suggestion, if people where interested.

The ideas I wrote in my extended suggestion, "Taking it one step 
further", I think that those can have benefits over string mixins. 
Basically allowing you to pass the whole body of a class declaration to 
a function, as a delegate, with a syntax looking like Java annotations.

-- 
/Jacob Carlborg


More information about the Digitalmars-d mailing list