the proposed new syntax
r{var1=@a; and var2=@foo}

is replaced by a tuple:
("var1=", a, "; and var2=", foo)
where @ denotes escaping symbols.

@ itself be escaped with \@.

optionally, expressions can be incorporated:
r{a2=@(a*2); and fooU=@(foo.toUpper)}

I've actually already implemented this feature via a mixin, and find it extremely useful, but removing the mixing via this proposal would make it even more palatable. It works using a simple grammar that searches for valid identifiers after a @, or finds nested expressions nested inside parenthesis (arbitrary nesting allowed).

Proper tooling will syntax highlight correctly the nested variables.


This feature is especially useful when there are a few variables involved, as alternatives are clunky


use cases:
A) simple string formatting (eg: formattedWrite)
----
q{first var=@a, second=@b, third=@c!}.foo
vs:
("first var=",a," second=",b," third=",c,"!").foo // `",,"` for a single `@`
("first var=%s, second=%s, third=%s!", a, b, c).foo => // error prone esp
with many variables
or alternatives involving ~ :
("first var="~a.to!string~", second="~b.to!string~",
third="~c.to!string~"!").foo
//clunky

B) parsing (eg formattedRead)
same advantages as above

On 2013-10-31 22:24, Timothee Cour wrote:
> the proposed new syntax
> r{var1=@a; and var2=@foo}
>
> is replaced by a tuple:
> ("var1=", a, "; and var2=", foo)
> where @ denotes escaping symbols.
>
> @ itself be escaped with \@.
>
> optionally, expressions can be incorporated:
> r{a2=@(a*2); and fooU=@(foo.toUpper)}

Would @ be the best symbol for this. It might get confusing with UDA's.

-- 
/Jacob Carlborg

$ is another obvious choice (eg in shell expansion)
but # could also be good as it's very much unused in D.


On Thu, Oct 31, 2013 at 2:37 PM, Jacob Carlborg <doob@me.com> wrote:

> On 2013-10-31 22:24, Timothee Cour wrote:
>
>> the proposed new syntax
>> r{var1=@a; and var2=@foo}
>>
>> is replaced by a tuple:
>> ("var1=", a, "; and var2=", foo)
>> where @ denotes escaping symbols.
>>
>> @ itself be escaped with \@.
>>
>> optionally, expressions can be incorporated:
>> r{a2=@(a*2); and fooU=@(foo.toUpper)}
>>
>
> Would @ be the best symbol for this. It might get confusing with UDA's.
>
> --
> /Jacob Carlborg
>

btw, another argument is type safety: my proposal has type safety inherited from typesafe variadic templates, whereas the "%s" way of doing things is fragile:

import std.stdio;
void main(){
  writefln("%s%s%s\n",1,2);//crash at RT
  writefln("%s%s\n",1,2,3);//silently accepts even though 1 more argument
  writefln("%s%d\n",1,"foo");//crash at RT: wrong format specifier
}


On Thu, Oct 31, 2013 at 2:37 PM, Jacob Carlborg <doob@me.com> wrote:

> On 2013-10-31 22:24, Timothee Cour wrote:
>
>> the proposed new syntax
>> r{var1=@a; and var2=@foo}
>>
>> is replaced by a tuple:
>> ("var1=", a, "; and var2=", foo)
>> where @ denotes escaping symbols.
>>
>> @ itself be escaped with \@.
>>
>> optionally, expressions can be incorporated:
>> r{a2=@(a*2); and fooU=@(foo.toUpper)}
>>
>
> Would @ be the best symbol for this. It might get confusing with UDA's.
>
> --
> /Jacob Carlborg
>

On 2013-10-31 22:47, Timothee Cour wrote:
> $ is another obvious choice (eg in shell expansion)
> but # could also be good as it's very much unused in D.

Yeah, # is only used for #line, which should be less common than $.

-- 
/Jacob Carlborg

On Thursday, 31 October 2013 at 21:24:42 UTC, Timothee Cour wrote:

> I've actually already implemented this feature via a mixin, and find it
> extremely useful, but removing the mixing via this proposal would make it
> even more palatable. It works using a simple grammar that searches for
> valid identifiers after a @, or finds nested expressions nested inside
> parenthesis (arbitrary nesting allowed).
>
> Proper tooling will syntax highlight correctly the nested variables.
>

Would you mind posting your code?

Thanks
Dan

actually an important use case of this feature is to help writing domain
specific language inputs, eg writing a python file inside D, or config /
plain text files.
# is common in many languages (eg python/bash etc) as a comment.

@ would be inside string literal so should cause little confusion from D's side, but for example would force one to escape '@' in email addresses (more rare).

Frankly, this is bike shedding though; let's assume we pick one in http://www.ascii-code.com/ and focus on whether we can agree on this feature.

I'm using it extensively for great benefit: more DRY code, less spurious files, cleaner integration with D.



On Fri, Nov 1, 2013 at 12:33 AM, Jacob Carlborg <doob@me.com> wrote:

> On 2013-10-31 22:47, Timothee Cour wrote:
>
>> $ is another obvious choice (eg in shell expansion)
>> but # could also be good as it's very much unused in D.
>>
>
> Yeah, # is only used for #line, which should be less common than $.
>
> --
> /Jacob Carlborg
>

On Tuesday, 5 November 2013 at 22:26:23 UTC, Timothee Cour wrote:
> Frankly, this is bike shedding though; let's assume we pick one in
> http://www.ascii-code.com/ and focus on whether we can agree on this
> feature.
>
> I'm using it extensively for great benefit: more DRY code, less spurious
> files, cleaner integration with D.
>

Isn't this just string interpolation which many/most languages have?
Yes - it is a great feature. Do you have working code on github that others may use?

Thanks
Dan

While thinking on a new string literal that may support DSL's, the syntax
should optionally receive a language specification on opening.
The thing that sucks most about DSL's is that the IDE can't syntax hilight
them, but if it was provided what language the string was, then a smart IDE
could apply syntax hilighting for that language within the scring scope.
Eg, this sort of thing is supported in html, which is usually hilighted
correctly by IDE's:
  <script type="text/javascript"> or <script language="javascript">

And exists in many other places too.


On 6 November 2013 08:26, Timothee Cour <thelastmammoth@gmail.com> wrote:

> actually an important use case of this feature is to help writing domain
> specific language inputs, eg writing a python file inside D, or config /
> plain text files.
> # is common in many languages (eg python/bash etc) as a comment.
>
> @ would be inside string literal so should cause little confusion from D's side, but for example would force one to escape '@' in email addresses (more rare).
>
> Frankly, this is bike shedding though; let's assume we pick one in http://www.ascii-code.com/ and focus on whether we can agree on this feature.
>
> I'm using it extensively for great benefit: more DRY code, less spurious files, cleaner integration with D.
>
>
>
> On Fri, Nov 1, 2013 at 12:33 AM, Jacob Carlborg <doob@me.com> wrote:
>
>> On 2013-10-31 22:47, Timothee Cour wrote:
>>
>>> $ is another obvious choice (eg in shell expansion)
>>> but # could also be good as it's very much unused in D.
>>>
>>
>> Yeah, # is only used for #line, which should be less common than $.
>>
>> --
>> /Jacob Carlborg
>>
>
>

On Tue, Nov 5, 2013 at 3:19 PM, Daniel Davidson <nospam@spam.com> wrote:
>
>
> Isn't this just string interpolation which many/most languages have? Yes - it is a great feature. Do you have working code on github that others may use?
>
> Thanks
> Dan
>

This is more powerful than string interpolation, as it generates a tuple instead of generating a string:

in my proposal,

r{var1=@a; and var2=@foo}
is replaced by
("var1=", a, "; and var2=", foo)
instead of text("var1=,a,"; and var2=",foo), as done in most languages like
you mention.

This exploits D's powerful variadic templates and is more powerful:
we can get string interpolation by simply using r{...}.text
but we can do more fancy things if needed (eg apply formatting, etc),
without requiring additional types of string litterals, as needed in scala (
http://docs.scala-lang.org/overviews/core/string-interpolation.html)