New syntax for string mixins

[Nick Sabalausky]

"Jacob Carlborg" <doob at me.com> wrote in message 
news:iee4en$ttb$1 at digitalmars.com...
> On 2010-12-16 21:35, Nick Sabalausky wrote:
>> "Jacob Carlborg"<doob at me.com>  wrote in message
>> news:iedpbg$3i0$1 at digitalmars.com...
>>> On 2010-12-15 23:00, Nick Sabalausky wrote:
>>>>
>>>> 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);
>>>
>>
>> Yea, my point was just that the "@..." stuff could work either way, with 
>> the
>> string-based system or with your delegate-based one.
>>
>> I don't mean to come across like I'm ignoring or against the idea of the
>> whole delegate aspect, and I understand that the main point of the OP is 
>> to
>> replace the strings with delegates, but with the q{...} syntax and
>> string-templating, I'm still struggling to see a big enough benefit 
>> compared
>> to the status quo. I see that using delegates instead of strings could
>> probably be made to work, but my questions are "For what benefit(s)?" and
>> "Would those benefits be sufficient to warrant the change?" I'm not
>> necessarily saying the answer is "no", but I'm unconvinced so far.
>>
>> And here's another thing: Suppose we got a Ruby/PHP-like syntax for
>> embedding code substitutions directly into a string (which would have 
>> other
>> useful applications besides mixins):
>>
>> auto name = "Joe";
>> auto msg = "hello #{name}, whaddup?";
>> mixin( q{ int #{name} = 7; } );
>> Joe++;
>>
>> Would that eliminate much (or all) of the benefit of the delegate 
>> approach?
>
> I guess using q{...} with string interpolation is very similar to the 
> delegate approach. It just feels wrong passing around strings to represent 
> code.

Well, code *is* text after all. But I know what you mean - after all, it 
does have more semantic structure than just ordinary generic strings.

> I haven't though much about it but with delegates one could at lest hope 
> for better help from the compiler validating the code. I don't know how 
> IDEs will treat q{...} but with delegates you would get the full benefit 
> of the IDE like autocompletion and similar features.
>

My editor (Programmer's Notepad 2, based off Scintilla) handles that fine. 
It doesn't know anything about q{}, so it assumes it's an identifier ("q") 
followed by a normal code block. And since it doesn't try to do any 
grammatical/semantic validation (only lexical, and only for the purpose of 
highlighting) it doesn't complain about "identifier { ... }" being invalid 
or any of the indentifiers-to-be-replaced inside of it being undeclared.

But for fancier IDE's, like Eclipse with Descent or DDT, I don't know - 
that's a good question.

OTOH, even with the delegate approach, I'm assuming that delegate would 
still get evaluated in a different context from where it's defined (which 
you'd probably want). So that might still cause some trouble with the more 
intelligent IDEs trying to tell you that identifierXYZ isn't accessable from 
within what it thinks is the delegate's scope.