On 08/12/2018 9:59 AM, H. S. Teoh wrote:
> I think we need to sell it to W&A from this angle.:-D   This is a lot
> more convincing than "PHP-style interpolated strings would be nice, can
> we haz it plz, kthxbye".

Just a warning, what I'm seeing right now is compiler hooks into the language (I've wanted these before). It is very unlikely from what I remember what W&A have said that it would be accepted.

Whatever semantics+syntax that is came up with, you may need to be a bit careful so that it is clear what is going on to the compiler and user.

On 12/7/18 3:59 PM, H. S. Teoh wrote:
> On Fri, Dec 07, 2018 at 03:13:09PM -0500, Steven Schveighoffer via Digitalmars-d wrote:
> [...]
>> My vision of formatted would be simply a pairing of a format specifier
>> with a value. It would be up to the function to interpret that (i.e.
>> text, or inlineformat or whatever you like).
>>
>> But the point is you are coupling the format with the value in the
>> same place. Which is the idea behind the "named parameters" that you
>> have.
>>
>> I don't want the language to do any sort of formatting at all. That's
>> a library feature. We just need the interpolation feature to give us a
>> nicer way to call it.
> [...]
> 
> I see.  So that means what we really want is for the language to
> translate interpolated strings into tuples that can then be processed by
> library code. In other words, it's not really an interpolated string
> anymore, it's a kind of "tuple literal" with convenient syntax. It has
> general applicability, and can be used for all sorts of interesting
> things beyond just interpolated strings.  Like your database query
> example.  In fact, it can even form the basis for implementing my named
> parameters idea.  Once we have it in tuple form, it can be used for all
> sorts of things.  (Which makes me wonder if we can even make it a
> replacement for std.meta.AliasSeq ...) It would be an enabler of cool
> new D idioms, rather than mere syntactic sugar for a "niche" use case.

I think we are all finally on the same page (which I didn't realize we weren't, sorry about that!)

The selling of the idea is the hard part, Jonathan Marler has already implemented it, and the spec is super-simple as you say.

I think part of the confusion here is that we are calling it string interpolation. It's not the same as what most languages use for string interpolation. It's really something more like "string formatted alias sequence" or "string interpolation tuple". That should be reflected in the actual DIP.

What's central to the utility is that it's based on string literals (runtime strings will NOT work here), and therefore, has the potential to be used in mixins, and in compile-time alias sequences. Sequences of expressions split by strings are so common in D, it just makes complete sense to me.

-Steve

On Friday, 7 December 2018 at 22:12:18 UTC, Steven Schveighoffer wrote:
> I think we are all finally on the same page (which I didn't realize we weren't, sorry about that!)
>
> The selling of the idea is the hard part, Jonathan Marler has already implemented it, and the spec is super-simple as you say.
>
> I think part of the confusion here is that we are calling it string interpolation. It's not the same as what most languages use for string interpolation. It's really something more like "string formatted alias sequence" or "string interpolation tuple". That should be reflected in the actual DIP.
>
> What's central to the utility is that it's based on string literals (runtime strings will NOT work here), and therefore, has the potential to be used in mixins, and in compile-time alias sequences. Sequences of expressions split by strings are so common in D, it just makes complete sense to me.
>
> -Steve

I sent you a github invite to the contributors group for the DIP. If you are okay with it, could you clarify what you said in the DIP? Thanks!

On Friday, 7 December 2018 at 22:12:18 UTC, Steven Schveighoffer wrote:
> On 12/7/18 3:59 PM, H. S. Teoh wrote:
>> [...]
>
> I think we are all finally on the same page (which I didn't realize we weren't, sorry about that!)
>
> [...]

I recall the same confusion back when I was implementing it.  The term "intupleated strings" came to mind...maybe a little to cheeky though :)

On 12/7/18 5:26 PM, Jonathan Marler wrote:
> On Friday, 7 December 2018 at 22:12:18 UTC, Steven Schveighoffer wrote:
>> On 12/7/18 3:59 PM, H. S. Teoh wrote:
>>> [...]
>>
>> I think we are all finally on the same page (which I didn't realize we weren't, sorry about that!)
>>
>> [...]
> 
> I recall the same confusion back when I was implementing it.  The term "intupleated strings" came to mind...maybe a little to cheeky though :)

Yes, I immediately read that as interpolated strings :) The human brain doesn't notice slightly different spellings (https://www.mrc-cbu.cam.ac.uk/people/matt.davis/cmabridge/)

I don't think it would have the desired effect, but it is clever.

-Steve

On 12/7/18 5:24 PM, o wrote:
> On Friday, 7 December 2018 at 22:12:18 UTC, Steven Schveighoffer wrote:
>> I think we are all finally on the same page (which I didn't realize we weren't, sorry about that!)
>>
>> The selling of the idea is the hard part, Jonathan Marler has already implemented it, and the spec is super-simple as you say.
>>
>> I think part of the confusion here is that we are calling it string interpolation. It's not the same as what most languages use for string interpolation. It's really something more like "string formatted alias sequence" or "string interpolation tuple". That should be reflected in the actual DIP.
>>
>> What's central to the utility is that it's based on string literals (runtime strings will NOT work here), and therefore, has the potential to be used in mixins, and in compile-time alias sequences. Sequences of expressions split by strings are so common in D, it just makes complete sense to me.
> 
> I sent you a github invite to the contributors group for the DIP. If you are okay with it, could you clarify what you said in the DIP? Thanks!

Thanks, I got the invite, will respond there.

-Steve

On Friday, 7 December 2018 at 20:59:51 UTC, H. S. Teoh wrote:
> I think we need to sell it to W&A from this angle. :-D  This is a lot more convincing than "PHP-style interpolated strings would be nice, can we haz it plz, kthxbye".
>
>
> T

Also, see Andrei's comment: https://github.com/dlang/dmd/pull/7988#issuecomment-375760720

On Friday, 7 December 2018 at 23:46:45 UTC, o wrote:
> Also, see Andrei's comment: https://github.com/dlang/dmd/pull/7988#issuecomment-375760720

He seems to also have the misunderstanding that was common earlier in this thread that tuple == std.typecons.

That is false.

On Fri, Dec 07, 2018 at 11:46:45PM +0000, o via Digitalmars-d wrote:
> On Friday, 7 December 2018 at 20:59:51 UTC, H. S. Teoh wrote:
> > I think we need to sell it to W&A from this angle. :-D  This is a lot more convincing than "PHP-style interpolated strings would be nice, can we haz it plz, kthxbye".
> > 
> > 
> > T
> 
> Also, see Andrei's comment: https://github.com/dlang/dmd/pull/7988#issuecomment-375760720

I think the DIP must take Andrei's comment into account. I.e., we should create possible library solutions, and discuss the pros and cons, esp. to enumerate the ways in which a language-backed implementation would be superior.

A few specific points that come to mind:

- Mixins essentially grant the callee unrestricted access to the
  caller's scope.  This leads to the possibility of surprising behaviour
  (e.g., what looks like an innocent function call or interpolated
  literal causes local variables to change, that aren't directly passed
  to the function).  Mixins are also a last-resort feature that we
  generally don't prefer if less intrusive means are available to
  achieve the desired effect.

- Having the language segment the literal into a tuple of strings and
  aliases (as opposed to outright string interpolation) has
  applicability beyond mere string interpolations. Steven's database
  idea would be great to use to strengthen this point.  We could also
  think up some more advanced examples that embed, e.g., functions
  (rather than merely variables) that the callee can use to transform
  the input string segments in interesting ways that go far beyond what
  mere string interpolation does.  Code generation techniques come to
  mind (e.g., specify a function that generates a loop around a block of
  code specified in string form).

- Andrei's last point about needing to import std.typecons is false.
  Built-in tuples (aka AliasSeq) does not depend on
  std.typecons.AliasSeq; it's a compiler construct that AliasSeq merely
  gives a useful name for.  What we're really doing is turning an i"..."
  literal into a *template argument list*.

Andrei also mentioned nicer mixin syntaxes, which was also discussed in this thread.  Our discussions should be rephrased and summarized in a way that directly answers Andrei's points.


T

-- 
People tell me I'm stubborn, but I refuse to accept it!

On Friday, 7 December 2018 at 23:56:48 UTC, Adam D. Ruppe wrote:
> On Friday, 7 December 2018 at 23:46:45 UTC, o wrote:
>> Also, see Andrei's comment: https://github.com/dlang/dmd/pull/7988#issuecomment-375760720
>
> He seems to also have the misunderstanding that was common earlier in this thread that tuple == std.typecons.

This is probably going to confuse more people, so we should refer to them as "sequences" in the DIP. Also, I am calling it "String Sequence Literals" instead of "String Interpolation" because it is more broad - more than just interpolation can be done with this.