View mode: basic / threaded / horizontal-split · Log in · Help
December 16, 2010
Re: New syntax for string mixins
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
December 16, 2010
Re: New syntax for string mixins
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
December 16, 2010
Re: New syntax for string mixins
"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.
December 16, 2010
Re: New syntax for string mixins
"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?
December 16, 2010
Re: New syntax for string mixins
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
December 16, 2010
Re: New syntax for string mixins
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
December 16, 2010
Re: New syntax for string mixins
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
December 16, 2010
Re: New syntax for string mixins
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
December 16, 2010
Re: New syntax for string mixins
"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.
December 16, 2010
Re: New syntax for string mixins
"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.
1 2 3 4 5 6
Top | Discussion index | About this forum | D home