April 17, 2017
On 2017-04-16 18:10, Nick Sabalausky (Abscissa) wrote:

> What I think would be ideal is a language enhancement to allow "interp"
> to do its job without the extra syntactical noise. That would not only
> give us good interpolates strings, but would likely have other
> applications as well.

It's called AST macros ;)

-- 
/Jacob Carlborg
April 17, 2017
On Sunday, 16 April 2017 at 16:10:15 UTC, Nick Sabalausky (Abscissa) wrote:
> Yea, and note, I'm still open to the idea of better names than "interp". I'm still not entirely happy with that name. I'm even half-tempted to use "_".
When I needed interpolation, I did not know about this library. So I create my own implementation and name it `expand`. I only needed class properties and did not support the expression, so this can not be considered a general solution, but name `expand` seems to be good for me.

unittest
{
	class InterTest
	{
		static int a = 1;
		static string bb = "--bb--";
		
		mixin ExpandLocals;
		
		auto getInterpolated()
		{
			return expand!"a is $a, bb is $bb, and this is just $ sign";
		}
	}
	
	assert((new InterTest).getInterpolated() == "a is 1, bb is --bb--, and this is just $ sign");
	
}

> What I think would be ideal is a language enhancement to allow "interp" to do its job without the extra syntactical noise. That would not only give us good interpolates strings, but would likely have other applications as well.
Now I spend thinking some time about it and didn't find common solution without text mixin too.
April 17, 2017
On Sunday, 16 April 2017 at 08:01:02 UTC, Jacob Carlborg wrote:
> On 2017-04-15 22:04, Jonas Drewsen wrote:
>> [...]
>
> My initial reaction is that this is something that can be implemented as library code if the language would have support for AST macros.
>
> On the other hand, this is something I would like to have in the language or the standard library.

I'm in favor of AST macros but I think that has been shot down
by Walter already afaik.


April 17, 2017
On Monday, April 17, 2017 18:10:23 Jonas Drewsen via Digitalmars-d wrote:
> On Sunday, 16 April 2017 at 08:01:02 UTC, Jacob Carlborg wrote:
> > On 2017-04-15 22:04, Jonas Drewsen wrote:
> >> [...]
> >
> > My initial reaction is that this is something that can be implemented as library code if the language would have support for AST macros.
> >
> > On the other hand, this is something I would like to have in the language or the standard library.
>
> I'm in favor of AST macros but I think that has been shot down by Walter already afaik.

Walter is very much against AST macros and has said so on several occasions. It's one of those features that probably has about as much chance making it into the language as a snowball has in hell...

- Jonathan M Davis

April 17, 2017
On Sunday, 16 April 2017 at 00:25:19 UTC, Stanislav Blinov wrote:
> On Saturday, 15 April 2017 at 23:58:18 UTC, Adam D. Ruppe wrote:
>> On Saturday, 15 April 2017 at 23:11:42 UTC, Stanislav Blinov wrote:
>>> How about... it removes an import or two?
>>
>> It doesn't actually remove the dependency, it is just syntax sugar over it (there is precedent for this in the language, the pow operator calls a Phobos function, but it means you don't actually gain decoupling of modules).
>
> As presented, it doesn't. But it can be implemented in a way that it does. The compiler is capable of conversions without ever needing std.conv, and if custom .toString() is required, it will already be available anyway.

I guess the phobos dependency could be removed with some extra work
which I'll happily do. But the main worry I hear from people is the added
language complexity which isn't going away.






April 17, 2017
On Sunday, 16 April 2017 at 16:10:15 UTC, Nick Sabalausky (Abscissa) wrote:
> On 04/15/2017 04:35 PM, crimaniak wrote:
>> On Saturday, 15 April 2017 at 20:04:13 UTC, Jonas Drewsen wrote:
>>> The compiler will basically lower the $"..." string to a mixin that
>>> concatenates
>>> the expression parts of the (inside the {}) and the plain text parts.
>> It's easy implementable as a library (see
>> https://github.com/Abscissa/scriptlike#string-interpolation) so it does
>> not seem like a good idea to modify the language, only to change
>> interp!"" to $"".
>
> Yea, and note, I'm still open to the idea of better names than "interp". I'm still not entirely happy with that name. I'm even half-tempted to use "_".
>
> The only one problem I've found with doing it in library though: Far as I could tell, it seems to require the caller uses string mixins, which makes actually using it a little uglier and more verbose than I would like.

I was trying to get it shorter:
// From
// Output: The number 21 doubled is 42!
int num = 21;
writeln( mixin(interp!"The number ${num} doubled is ${num * 2}!") );

defining a new method exho! (derived from echo + mixin...:-)

  auto exho(string x)(){
     return mixin("writeln("~interp!x~")");}

You can just write:

   exho!"The number ${num} doubled is ${num * 2}!"

This now looks more like "normal" scripting than

   writeln( mixin(interp!"The number ${num} doubled is ${num * 2}!") );

> Maybe I'm overlooking something obvious, but I haven't been able to find a way to change it to either a template mixin or even just a plain template without sacrificing to whole point of interpolated strings: specifying the arguments 100% inline.
>
> What I think would be ideal is a language enhancement to allow "interp" to do its job without the extra syntactical noise. That would not only give us good interpolates strings, but would likely have other applications as well.

I am not against the idea making string interpolations part of the language, in vibe.d diet templates the extrapolation is marked with #{var}, the ruby style, I like this too.
At the beginning I thought this is already part of d.

Regards mt.

April 17, 2017
On Saturday, 15 April 2017 at 20:04:13 UTC, Jonas Drewsen wrote:
> Hi all
>
>   I've been wanting to have support for interpolated strings in D for some time now that will allow you to write e.g.:
>
> auto a = 7;
> writeln( $"{a} times 3 is {a*3}" );
>
> Code speaks louder that words so I've made a PR that adds this support to ddmd as a RFC [1].
>
> The compiler will basically lower the $"..." string to a mixin that concatenates
> the expression parts of the (inside the {}) and the plain text parts.
>
> I do recognize that this is not part of the 2017 H1 plan but I also believe such smaller improvements added regularly can make the language both more productive and attractive.
>
> In case this addition gets a thumbs up I will of course improve test coverage and any needed quality of implementation.
>
> [1] https://github.com/dlang/dmd/pull/6703

Seems like there are mixed opinions about inclusion of a thing like this.

Looking at all the old PRs on dlang github slowly bit rotting it makes me
wonder how not to end up in that pool.

I think that history has shown that Walter/Andrei are gatekeepers on what
will ever get into the language. For the sake of contributers (incl. me or course :) ) it would make sense to get a preliminary "never going in" clarification by them early on. Even before a DIP has been written because writing that takes a good amount of effort.

Also collect these declined language change decisions (such as AST Macros) on the wiki for future contributers to scan through before anything else. I volunteer to add "interpolated strings" to the page in case it gets declined. The page could also list pre-approved language changes such as async functions (which Walter wants afaik).

I guess the main question is really to Walter and Andrei if we could get some kind "never going in" or "could be considered" clarification on e.g. news group threads named like e.g. "Language Design Change: Interpolated string"? Based on that the next steps: DIP, PR etc. step would take place.























April 17, 2017
On Saturday, 15 April 2017 at 20:04:13 UTC, Jonas Drewsen wrote:
> Hi all
>
>   I've been wanting to have support for interpolated strings in D for some time now that will allow you to write e.g.:
>
> auto a = 7;
> writeln( $"{a} times 3 is {a*3}" );
>
> Code speaks louder that words so I've made a PR that adds this support to ddmd as a RFC [1].
>
> The compiler will basically lower the $"..." string to a mixin that concatenates
> the expression parts of the (inside the {}) and the plain text parts.
>
> I do recognize that this is not part of the 2017 H1 plan but I also believe such smaller improvements added regularly can make the language both more productive and attractive.
>
> In case this addition gets a thumbs up I will of course improve test coverage and any needed quality of implementation.
>
> [1] https://github.com/dlang/dmd/pull/6703

C# got this feature recently. I didn't expect it to be a significant difference, but I do find it a substantial improvement. Not only does it clearly show what goes where, but it's so much cleaner and more convenient.
April 17, 2017
On Monday, 17 April 2017 at 19:12:37 UTC, Martin Tschierschke wrote:
> defining a new method exho! (derived from echo + mixin...:-)
>
>   auto exho(string x)(){
>      return mixin("writeln("~interp!x~")");}
>
> You can just write:
>
>    exho!"The number ${num} doubled is ${num * 2}!"

It requires 'num' to be available to the exho function definition so will not
work in the general case.
April 18, 2017
On 2017-04-17 21:28, Jonas Drewsen wrote:

> The page could also list pre-approved language
> changes such as async functions (which Walter wants afaik).

Another feature that can be implemented with AST macros. This is starting to get ridicules. So many features have been added and are talked about that can be implemented with AST macros instead. Same as with the scope/safe related DIPs. Many smallish specialized features are added instead of a generic feature that can handle all of them. Increasing the complexity of the language.

-- 
/Jacob Carlborg