On Saturday, 8 December 2018 at 00:58:43 UTC, o wrote:
> 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.

For reference, the official documentation on dlang.org refers to them as "compile-time sequences" [1] or "AliasSeqs" [2].

Also, as long as we're bikeshedding, my vote for the title would be something like "String Syntax for Compile-Time Sequences", so that there's no potential for confusion between "String (Sequence Literals)" and "(String Sequence) Literals".

[1] https://dlang.org/articles/ctarguments.html
[2] https://dlang.org/spec/template.html#variadic-templates

On Friday, December 7, 2018 5:58:43 PM MST o via Digitalmars-d wrote:
> 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.

Personally, I'd just use the term AliasSeq, because that's what the associated template for them in Phobos is called. Just about anything else is going to be confusing. It's really unfortunate that Walter originally decided to call them tuples given that they aren't quite tuples, but there really isn't a good term for them ultimately. As it is, AliasSeq was just the best of a bad set of choices, but at least it's clear what you mean what you use the term, whereas just about anything else breeds confusion.

- Jonathan M Davis

On 12/7/18 9:04 PM, Jonathan M Davis wrote:
> On Friday, December 7, 2018 5:58:43 PM MST o via Digitalmars-d wrote:
>> 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.
> 
> Personally, I'd just use the term AliasSeq, because that's what the
> associated template for them in Phobos is called. Just about anything else
> is going to be confusing. It's really unfortunate that Walter originally
> decided to call them tuples given that they aren't quite tuples, but there
> really isn't a good term for them ultimately. As it is, AliasSeq was just
> the best of a bad set of choices, but at least it's clear what you mean what
> you use the term, whereas just about anything else breeds confusion.

But it's not an AliasSeq. It's simply a list of items.

for example, I want this to work:

writeln(i"a + b = ${a+b}");

And this compiles:

writeln("a + b = ", a + b);

But this does not:

writeln(AliasSeq!("a + b = ", a + b));

-Steve

On Fri, Dec 07, 2018 at 09:29:10PM -0500, Steven Schveighoffer via Digitalmars-d wrote: [...]
> But it's not an AliasSeq. It's simply a list of items.
> 
> for example, I want this to work:
> 
> writeln(i"a + b = ${a+b}");
> 
> And this compiles:
> 
> writeln("a + b = ", a + b);
> 
> But this does not:
> 
> writeln(AliasSeq!("a + b = ", a + b));
[...]

Hmph.  I forgot about this limitation of compile-time tuples aka AliasSeq: you cannot capture expressions this way. :-(

The best I could come up with was to replicate std.typecons.Tuple:

	import std.stdio;
	alias AliasSeq(T...) = T;
	struct Tuple(T...)
	{
		T t;
		alias t expand;
	}
	auto func(Args...)(Args args)
	{
		return Tuple!Args(args);
	}
	void main() {
		int a=1, b=2;

		// Desired effect
		writeln("Sum of ", a, " and ", b, " is ", a+b);

		// NG: doesn't compile:
		//writeln(AliasSeq!("Sum of ", a, " and ", b, " is ", a+b));

		// This works (but is ugly)
		writeln(func("Sum of ", a, " and ", b, " is ", a+b).expand);
	}


This certainly puts a damper in our proposal. :-(

How does Marler's implementation behave? Does it capture expressions? If it does, we have good news (but we'll have to document this clearly, since it would be unprecedented in the current language).  If not, we'll have to think more carefully about how to implement this.


T

-- 
Doubtless it is a good thing to have an open mind, but a truly open mind should be open at both ends, like the food-pipe, with the capacity for excretion as well as absorption. -- Northrop Frye

On Saturday, 8 December 2018 at 02:49:46 UTC, H. S. Teoh wrote:
> Hmph.  I forgot about this limitation of compile-time tuples aka AliasSeq: you cannot capture expressions this way. :-(

The problem with AliasSeq!() is the !() part - it is passing them as compile-time arguments, and thus it must be available at compile time *for the template it is being passed to*.

But the compiler itself has no such limitation. And as proof, consider std.traits.Parameters. You can set items in that to runtime values and pass them to functions... just not *templates* because the variables a+b need to be available.

Also, struct.tupleof works fine. We aren't capturing expressions per se, we are capturing the values of those evaluating those expressions. Passing it to a compile time thing would complain, but passing it to a runtime function would be fine, just like how

Template!(a+b)

only works if they can be CTFE'd, whereas

Function(a+b)

is totally fine

On 12/7/18 9:49 PM, H. S. Teoh wrote:
> On Fri, Dec 07, 2018 at 09:29:10PM -0500, Steven Schveighoffer via Digitalmars-d wrote:
> [...]
>> But it's not an AliasSeq. It's simply a list of items.
>>
>> for example, I want this to work:
>>
>> writeln(i"a + b = ${a+b}");
>>
>> And this compiles:
>>
>> writeln("a + b = ", a + b);
>>
>> But this does not:
>>
>> writeln(AliasSeq!("a + b = ", a + b));
> [...]
> 
> Hmph.  I forgot about this limitation of compile-time tuples aka
> AliasSeq: you cannot capture expressions this way. :-(
> 
> The best I could come up with was to replicate std.typecons.Tuple:
> 
> 	import std.stdio;
> 	alias AliasSeq(T...) = T;
> 	struct Tuple(T...)
> 	{
> 		T t;
> 		alias t expand;
> 	}
> 	auto func(Args...)(Args args)
> 	{
> 		return Tuple!Args(args);
> 	}

So this is completely different from an AliasSeq. An AliasSeq is a compile-time list, and ONLY allows symbols and values known at compile time. An expression like "a + b" cannot be aliased.

What your code is doing is making an AliasSeq of *types* and then assigning the given values to an instance of those types. That works, and is not dissimilar to what I expect the string list to do when used on a runtime function.

But we can't have this proposal without that support. So we have to say it's not exactly an AliasSeq.

I have a PR on the DIP right now, take a look, would appreciate input: https://github.com/jash11/DIPs/pull/3

> 	void main() {
> 		int a=1, b=2;
> 
> 		// Desired effect
> 		writeln("Sum of ", a, " and ", b, " is ", a+b);
> 
> 		// NG: doesn't compile:
> 		//writeln(AliasSeq!("Sum of ", a, " and ", b, " is ", a+b));
> 
> 		// This works (but is ugly)
> 		writeln(func("Sum of ", a, " and ", b, " is ", a+b).expand);
> 	}
> 
> 
> This certainly puts a damper in our proposal. :-(
> 
> How does Marler's implementation behave? Does it capture expressions? If
> it does, we have good news (but we'll have to document this clearly,
> since it would be unprecedented in the current language).  If not, we'll
> have to think more carefully about how to implement this.

I'm yet unclear yet whether the implementation behaves that way, but if it doesn't we should just change it so it does. But he has said (a bit ambiguously) that it does do expressions (comment in that PR).

If we can't get arbitrary expressions to work at runtime, then this proposal is no good.

-Steve

On Friday, December 7, 2018 7:29:10 PM MST Steven Schveighoffer via Digitalmars-d wrote:
> On 12/7/18 9:04 PM, Jonathan M Davis wrote:
> > On Friday, December 7, 2018 5:58:43 PM MST o via Digitalmars-d wrote:
> >> 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.
> >
> > Personally, I'd just use the term AliasSeq, because that's what the associated template for them in Phobos is called. Just about anything else is going to be confusing. It's really unfortunate that Walter originally decided to call them tuples given that they aren't quite tuples, but there really isn't a good term for them ultimately. As it is, AliasSeq was just the best of a bad set of choices, but at least it's clear what you mean what you use the term, whereas just about anything else breeds confusion.
> But it's not an AliasSeq. It's simply a list of items.
>
> for example, I want this to work:
>
> writeln(i"a + b = ${a+b}");
>
> And this compiles:
>
> writeln("a + b = ", a + b);
>
> But this does not:
>
> writeln(AliasSeq!("a + b = ", a + b));

*sigh* So, we'd be creating yet another similar concept with this? That seems really questionable. I can see why you'd want something like i"a + b = ${a+b}" to work, but we already have enough confusion around "tuples" as it is without trying to add a third kind.

- Jonathan M Davis

On Saturday, 8 December 2018 at 03:11:10 UTC, Jonathan M Davis wrote:
> *sigh* So, we'd be creating yet another similar concept with this?

No, this is the SAME concept. It is just that the library cannot express it fully due to a limitation of the interface.

What we're talking about here is the compiler's internal tuple, as seen in things like obj.tupleof (which is a public name btw)

On 12/7/18 10:11 PM, Jonathan M Davis wrote:
> On Friday, December 7, 2018 7:29:10 PM MST Steven Schveighoffer via
> Digitalmars-d wrote:
>> On 12/7/18 9:04 PM, Jonathan M Davis wrote:
>>> On Friday, December 7, 2018 5:58:43 PM MST o via Digitalmars-d wrote:
>>>> 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.
>>>
>>> Personally, I'd just use the term AliasSeq, because that's what the
>>> associated template for them in Phobos is called. Just about anything
>>> else is going to be confusing. It's really unfortunate that Walter
>>> originally decided to call them tuples given that they aren't quite
>>> tuples, but there really isn't a good term for them ultimately. As it
>>> is, AliasSeq was just the best of a bad set of choices, but at least
>>> it's clear what you mean what you use the term, whereas just about
>>> anything else breeds confusion.
>> But it's not an AliasSeq. It's simply a list of items.
>>
>> for example, I want this to work:
>>
>> writeln(i"a + b = ${a+b}");
>>
>> And this compiles:
>>
>> writeln("a + b = ", a + b);
>>
>> But this does not:
>>
>> writeln(AliasSeq!("a + b = ", a + b));
> 
> *sigh* So, we'd be creating yet another similar concept with this? That
> seems really questionable. I can see why you'd want something like i"a + b =
> ${a+b}" to work, but we already have enough confusion around "tuples" as it
> is without trying to add a third kind.

I don't believe it's much different from tuple.expand. But I don't know what the limitations of the existing tuple-like things are.

Really, I just wanted it to expand into "as if you typed all those things individually separated by commas".

-Steve

On Saturday, 8 December 2018 at 03:04:35 UTC, Steven Schveighoffer wrote:

> So this is completely different from an AliasSeq. An AliasSeq is a compile-time list, and ONLY allows symbols and values known at compile time. An expression like "a + b" cannot be aliased.

That was the idea behind the `lazy alias` feature discussed earlier in this thread.  With that feature, I think expressions can be aliased.

`lazy void` already works for runtime arguments.  I think all that is required is `lazy alias` for compile-time arguments.

Mike