https://run.dlang.io/is/FbOnGI

import std.stdio;
template somefun()
{
     auto iterpolate(string s)()
     {
         //do some parsing
         return mixin(s[1 .. $]);
     }
}

enum enableInterpolate = "mixin somefun A; alias interpolate = A.iterpolate;";

void main()
{
    mixin(enableInterpolate);
    int a = 5;
    iterpolate!("$a").writeln;
}

https://gist.github.com/run-dlang/a0dce06b873b216680df673661e4b4e6

On Monday, 10 December 2018 at 12:34:33 UTC, Daniel Kozak wrote:
> https://gist.github.com/run-dlang/a0dce06b873b216680df673661e4b4e6

While I'm not sure of all the details of the implementation, I think the use of a mixed in templated nested function to enable access to the local scope without string mixin is inspired. Very clever idea.

On Monday, 10 December 2018 at 10:11:44 UTC, Daniel Kozak wrote:
> https://run.dlang.io/is/FbOnGI
>
> import std.stdio;
> template somefun()
> {
>      auto iterpolate(string s)()
>      {
>          //do some parsing
>          return mixin(s[1 .. $]);
>      }
> }
>
> enum enableInterpolate = "mixin somefun A; alias interpolate = A.iterpolate;";
>
> void main()
> {
>     mixin(enableInterpolate);
>     int a = 5;
>     iterpolate!("$a").writeln;
> }

Nice.

On Monday, 10 December 2018 at 10:11:44 UTC, Daniel Kozak wrote:
> https://run.dlang.io/is/FbOnGI
>
> import std.stdio;
> template somefun()
> {
>      auto iterpolate(string s)()
>      {
>          //do some parsing
>          return mixin(s[1 .. $]);
>      }
> }
>
> enum enableInterpolate = "mixin somefun A; alias interpolate = A.iterpolate;";
>
> void main()
> {
>     mixin(enableInterpolate);
>     int a = 5;
>     iterpolate!("$a").writeln;
> }
It is similar to my idea:

https://forum.dlang.org/post/uwbwjlmphpkllpeojjno@forum.dlang.org

(Where I define two functions mixinter(String)() and exho(string)()
to get a shorter expression when using scriptlike (dub package).)


So, yes very good :-)

On 12/10/18 7:45 AM, FeepingCreature wrote:
> On Monday, 10 December 2018 at 12:34:33 UTC, Daniel Kozak wrote:
>> https://gist.github.com/run-dlang/a0dce06b873b216680df673661e4b4e6
> 
> While I'm not sure of all the details of the implementation, I think the use of a mixed in templated nested function to enable access to the local scope without string mixin is inspired. Very clever idea.

Yeah, this looks a lot better than mixing in every interpolation.

I tried it out with adding arbitrary expressions, and it works like a charm: https://gist.github.com/run-dlang/6f682fe6ca12e02acc1c6af2c67632e7

It needs some polish around the parsing (need to handle parentheses and separating symbols with something other than space), but I'm pretty happy with the concept.

-Steve

On Monday, 10 December 2018 at 15:50:58 UTC, Steven Schveighoffer wrote:
> On 12/10/18 7:45 AM, FeepingCreature wrote:
>> On Monday, 10 December 2018 at 12:34:33 UTC, Daniel Kozak wrote:
>>> https://gist.github.com/run-dlang/a0dce06b873b216680df673661e4b4e6
>> 
>> While I'm not sure of all the details of the implementation, I think the use of a mixed in templated nested function to enable access to the local scope without string mixin is inspired. Very clever idea.
>
> Yeah, this looks a lot better than mixing in every interpolation.
>
> I tried it out with adding arbitrary expressions, and it works like a charm: https://gist.github.com/run-dlang/6f682fe6ca12e02acc1c6af2c67632e7
>
> It needs some polish around the parsing (need to handle parentheses and separating symbols with something other than space), but I'm pretty happy with the concept.
>
> -Steve

This is much better than having to mixin everywhere. A couple of things:

1) Can this be put in a module so that you don't have to mixin(enableInterpolation) but instead "import interp = std.interpolation;" or something similar?

2) This would unfortunately pollute the namespace and in code that uses interpolation heavily, you'd have to rename it to something non-clashy which I can see being quite annoying and a maintenance burden if it turns out to be a common thing to do. Maybe if it's just standardly called "interp" it may be alright though.

Cheers,
- Ali

On 12/10/18 11:11 AM, aliak wrote:
> This is much better than having to mixin everywhere. A couple of things:
> 
> 1) Can this be put in a module so that you don't have to mixin(enableInterpolation) but instead "import interp = std.interpolation;" or something similar?

No, you need a local mixin. Doing that import just imports the *symbol* into your namespace, but it doesn't give access to your namespace to the symbol.

> 2) This would unfortunately pollute the namespace and in code that uses interpolation heavily, you'd have to rename it to something non-clashy which I can see being quite annoying and a maintenance burden if it turns out to be a common thing to do. Maybe if it's just standardly called "interp" it may be alright though.

We can pass in the name we want to avoid conflicts.

So something like:

import std.interpolation;
mixin(enableInterpolate!"interp");

interp!("$a").writeln;

-Steve

On Monday, 10 December 2018 at 16:27:03 UTC, Steven Schveighoffer wrote:
> On 12/10/18 11:11 AM, aliak wrote:
>> This is much better than having to mixin everywhere. A couple of things:
>> 
>> 1) Can this be put in a module so that you don't have to mixin(enableInterpolation) but instead "import interp = std.interpolation;" or something similar?
>
> No, you need a local mixin. Doing that import just imports the *symbol* into your namespace, but it doesn't give access to your namespace to the symbol.
>

Au :(. Yeah that makes sense. Then I’m not sure I see how this improves things if it has to be mixed in to every scope you want to use interpolation for. The sparseness of interpolation might just make mixin(Interp!””)); more appealing.

On 12/10/18 11:36 AM, Aliak wrote:
> On Monday, 10 December 2018 at 16:27:03 UTC, Steven Schveighoffer wrote:
>> On 12/10/18 11:11 AM, aliak wrote:
>>> This is much better than having to mixin everywhere. A couple of things:
>>>
>>> 1) Can this be put in a module so that you don't have to mixin(enableInterpolation) but instead "import interp = std.interpolation;" or something similar?
>>
>> No, you need a local mixin. Doing that import just imports the *symbol* into your namespace, but it doesn't give access to your namespace to the symbol.
>>
> 
> Au :(. Yeah that makes sense. Then I’m not sure I see how this improves things if it has to be mixed in to every scope you want to use interpolation for. The sparseness of interpolation might just make mixin(Interp!””)); more appealing.

The benefit is that you only have to mixin once, whereas the usage does not require a mixin. It just goes next to your import statements.

However, multiple scopes may make this less appealing, as you would have to mixin at any inner scope that has a variable you want to deal with.

But I plan to write some string interpolation libraries based on this, would love to see a "better SQL" library for something like this.

Not sure if it mitigates the need for an interpolation DIP, as clearly this is going to be compile-time intensive, where the cleverness is stomped on by memory usage and slow compile times.

-Steve