On 2010-12-15 23:00, Nick Sabalausky wrote:
> "Jonathan M Davis"<jmdavisProg@gmx.com>  wrote in message
> news:mailman.1035.1292441722.21107.digitalmars-d@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);

-- 
/Jacob Carlborg

On 2010-12-16 11:18, Pelle Månsson wrote:
> On 12/15/2010 11:00 PM, Nick Sabalausky wrote:
>> "Jonathan M Davis"<jmdavisProg@gmx.com> wrote in message
>> news:mailman.1035.1292441722.21107.digitalmars-d@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 agree with this. Actually, just removing the parenthesis would be a
> huge gain for me.
>
>>> 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.
>>
>
> This could work, but I don't think anyone is suggesting completely
> replacing the mixin. I think @ could be a function/template thing, and
> have strings in a more explicit mixin"";
>
> Then again, inconsistency sucks.

The whole point of the idea/suggestion was to get rid of the strings. Then if the syntax I've suggested is translated into the string mixin syntax we have now then I would be fine with that.

-- 
/Jacob Carlborg

"Jacob Carlborg" <doob@me.com> wrote in message news:iednio$2vj5$1@digitalmars.com...
>
> I can't quite visualize how the final code will look like and as you say it's hard without a formal definition of AST macros. But I think somehow it would be possible, I mean instead of combining strings one combine expressions/syntax. But I don't know if it would be possible to combine incomplete expressions.
>

One parallel that may or may not be applicable, but might be worth considering, is dynamically building XHTML: Using a string-template system is generally found to work very well, but building it via a DOM (essentially an AST) is often considered a bit of a pain. I guess the simplest take-away would be that string-based approaches may be easier get working well. FWIW.

"Jacob Carlborg" <doob@me.com> wrote in message news:iedpbg$3i0$1@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?

On Thursday, December 16, 2010 11:28:03 Jacob Carlborg wrote:
> On 2010-12-15 23:00, Nick Sabalausky wrote:
> > "Jonathan M Davis"<jmdavisProg@gmx.com>  wrote in message news:mailman.1035.1292441722.21107.digitalmars-d@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

On 2010-12-16 21:13, Nick Sabalausky wrote:
> "Jacob Carlborg"<doob@me.com>  wrote in message
> news:iednio$2vj5$1@digitalmars.com...
>>
>> I can't quite visualize how the final code will look like and as you say
>> it's hard without a formal definition of AST macros. But I think somehow
>> it would be possible, I mean instead of combining strings one combine
>> expressions/syntax. But I don't know if it would be possible to combine
>> incomplete expressions.
>>
>
> One parallel that may or may not be applicable, but might be worth
> considering, is dynamically building XHTML: Using a string-template system
> is generally found to work very well, but building it via a DOM (essentially
> an AST) is often considered a bit of a pain. I guess the simplest take-away
> would be that string-based approaches may be easier get working well. FWIW.

I the case of XML I think it can be quite easy if you use the right libraries/tools. I think the easiest library I've used for building XML files is the Ruby library Bulilder, a code example using Builder can look like this:

xml = Builder::XmlMarkup.new

xml.person do
    xml.first_name "John"
    xml.last_name "Doe"
    xml.phone "5484654", :type => "mobile"
end

Which will generate this:

<person>
    <first_name>John</first_name>
    <last_name>Doe</last_name>
    <phone type="mobile">5484654</phone>
</person

Now I don't think that this library is a DOM library, which allows you to manipulate a DOM tree, it's something simpler that just generates XML.

Link: http://builder.rubyforge.org/

-- 
/Jacob Carlborg

On 2010-12-16 21:35, Nick Sabalausky wrote:
> "Jacob Carlborg"<doob@me.com>  wrote in message
> news:iedpbg$3i0$1@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. 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.

-- 
/Jacob Carlborg

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@gmx.com>   wrote in message
>>> news:mailman.1035.1292441722.21107.digitalmars-d@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

"Jacob Carlborg" <doob@me.com> wrote in message news:iee4en$ttb$1@digitalmars.com...
> On 2010-12-16 21:35, Nick Sabalausky wrote:
>> "Jacob Carlborg"<doob@me.com>  wrote in message news:iedpbg$3i0$1@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.

"Jacob Carlborg" <doob@me.com> wrote in message news:iee561$v5s$1@digitalmars.com...
> 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@gmx.com>   wrote in message news:mailman.1035.1292441722.21107.digitalmars-d@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.
>

It would seem to make sense to treat "chucks of code" the same way regardless of whether you're passing them around, mixing them in or instantiating them as a template.