"string interpolation"

[Jonathan Marler]

On Monday, 10 June 2019 at 08:53:56 UTC, Amex wrote:
> On Sunday, 9 June 2019 at 07:05:26 UTC, Jonathan Marler wrote:
>> On Sunday, 9 June 2019 at 05:24:29 UTC, Amex wrote:
>>> On Saturday, 8 June 2019 at 22:23:34 UTC, Nick Sabalausky 
>>> (Abscissa) wrote:
>>>> On 6/8/19 5:28 PM, Amex wrote:
>>>>> I and many others write a code that uses string mixins 
>>>>> simply to define a symbol based on others:
>>>>> 
>>>>> mixin(T~" "~id~" = "~value~");");
>>>>> 
>>>>> 
>>>>> This is very ugly and it is impossible to debug properly.
>>>>> 
>>>>> Why not allivate this issue? Is is so common that there can 
>>>>> be a short hand syntax that the compiler can decode 
>>>>> naturally.
>>>>> 
>>>>
>>>> There is work being done on the idea of interpolated strings:
>>>>
>>>> https://github.com/dlang/dmd/pull/7988
>>>
>>> This is not what I'm talking about. Similar but different. 
>>> I'm specifically talking about usage to replace string mixins.
>>>
>>> I'm not really talking about string interpolation at all. 
>>> It's symbol substitution.
>>>
>>> I've already given examples.
>>
>> So it sounds like you want `#X` to lower to `mixin(X)`? So in 
>> your example
>>
>> #T #id = #value;
>>
>> would be
>>
>> mixin(T) mixin(id) = mixin(value);
>>
>> I think that using the `#` character as a stand-in for mixin 
>> has been proposed before, and I think the idea has merit.  
>> However, as the language exists today there's no way to 
>> support the level of mixin you are suggesting.  Mixin only 
>> works at higher levels like expressions and statements, so you 
>> could do things like:
>>
>> mixin("const a = 1 + 2 + 3");
>>
>> and even things like:
>>
>> const a = 1 + mixin("2 + 3");
>>
>> but not things like this:
>>
>> mixin("const a") = 1 + 2 + 3;
>>
>> Or things like
>>
>> const mixin("a") = 1 + 2 + 3;
>>
>> Mixin can only appear at certain places in the grammar because 
>> the compiler needs to be able to analyze the code surrounding 
>> it before evaluating what's inside the mixin. This way you can 
>> use your own code at compile-time to generate what's inside 
>> the mixin without depending on what the mixin does to your 
>> code.
>>
>> In any case, with Adam Ruppe's full string interpolation 
>> proposal, you're example can be done with:
>>
>> mixin("$T $id = $value;");
>
>
> There is nothing that would stop the language from doing what 
> I'm suggesting...
>
>
> You agree that every statement S could be rewritten to 
> mixin("S"); and then evaluated by the compiler?

Yes I believe that's true.

>
> If so, then it can do what I suggest.
>
> 1. Scans statement for any symbol starting with special 
> char(#,$, or whatever).
>
> 2. If the statement has such a symbol then the statement is 
> wrapped in the mixin but all the symbols are expanded first.
>
>
> .e.g,
>
>
> $T $id = $value;
>
> $ is found in front of a symbol.
>
> simply expand symbols
>
> mixin(T~" "~id~" = "~value~";");
>
> with the appropriate to!string's when needed.
>

Ok I see how this is possible now.

> It is simply a rewrite rule that simplifies meta code and makes 
> certain string mixins more readable by making them look like 
> standard code. It makes it easier to debug. It is only for 
> symbol substitution so there is always a 1 to 1 relation. Any 
> errors in the resolved string can be mapped back in to the 
> original statement.
>

It seems like a pretty specific set of syntax/semantics to add to 
the language. I can't think of alot of cases that would benefit 
from it. If this is a very common pattern it could be justified. 
Can you point to a few places in some real code that could 
benefit from this pattern?

>
> It's purpose is to get rid of explicit mixin entirely for 
> certain types of very common string mixin statements.
>

Using mixin code shouldn't happen too often. Its powerfull but 
also comes with issues. Usually they are hidden away inside 
templates/functions in a library invisible to the user. Using a 
keyword like mixin makes them easy to find, and since they 
shouldn't happen too often, the extra characters don't create 
much of an issue.

However, your suggestion isn't as powerful or as dangerous as a 
full blown mixin, which makes them less concerning to have to 
keep track of, and it's still easy enough to search for `#`. So 
if it turns out to be useful enough then it could justify a 
language change. But I'm failing to think of useful cases for it. 
Can you share the cases you have thought this could be useful 
for? Pointing to existing code would be the best way to show them.