Thread overview | ||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
October 31, 2013 proposal: a new string litteral to embed variables in a string | ||||
---|---|---|---|---|
| ||||
Attachments:
| 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 |
October 31, 2013 Re: proposal: a new string litteral to embed variables in a string | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timothee Cour | 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 |
October 31, 2013 Re: proposal: a new string litteral to embed variables in a string | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg Attachments:
| $ 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
>
|
October 31, 2013 Re: proposal: a new string litteral to embed variables in a string | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg Attachments:
| 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 > |
November 01, 2013 Re: proposal: a new string litteral to embed variables in a string | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timothee Cour | 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 |
November 02, 2013 Re: proposal: a new string litteral to embed variables in a string | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timothee Cour | 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
|
November 05, 2013 Re: proposal: a new string litteral to embed variables in a string | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg Attachments:
| 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 > |
November 05, 2013 Re: proposal: a new string litteral to embed variables in a string | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timothee Cour | 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
|
November 06, 2013 Re: proposal: a new string litteral to embed variables in a string | ||||
---|---|---|---|---|
| ||||
Attachments:
| 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
>>
>
>
|
November 06, 2013 Re: proposal: a new string litteral to embed variables in a string | ||||
---|---|---|---|---|
| ||||
Posted in reply to Daniel Davidson Attachments:
| 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) |
Copyright © 1999-2021 by the D Language Foundation