On Monday, 19 August 2013 at 17:22:26 UTC, H. S. Teoh wrote:
> What I'd like to know, is how all of these proposals address the
> fundamental differences between "symbol tuples" (compile-time construct)

Those are not symbol tuples. For example, `int` is not a symbol. http://dlang.org/template.html#Symbol - only things that have identifiers and template instances are symbols.

> As far as I can tell, people
> are still confusing the two, and it's really not helping.

Completely removing TypeTuple from library (which native syntax will enable) will help to remove large part of confusion.

On Mon, Aug 19, 2013 at 07:34:38PM +0200, Dicebot wrote:
> On Monday, 19 August 2013 at 17:22:26 UTC, H. S. Teoh wrote:
> >What I'd like to know, is how all of these proposals address the fundamental differences between "symbol tuples" (compile-time construct)
> 
> Those are not symbol tuples. For example, `int` is not a symbol. http://dlang.org/template.html#Symbol - only things that have identifiers and template instances are symbols.

Well, OK, whatever they're supposed to be called. Compiler-tuples, or expression tuples, or whatever. See, part of the problem is that they just don't have any good name that correctly conveys what they are. Calling them "tuple" only adds to the confusion because of the conflation with std.range.Tuple.


> >As far as I can tell, people are still confusing the two, and it's really not helping.
> 
> Completely removing TypeTuple from library (which native syntax will enable) will help to remove large part of confusion.

That's only part of the problem. It doesn't solve the problem of conflation between these tuples and std.range.Tuple, and from what I can tell in these threads, people are still confusing the two. Both of them being named some kind of "tuple" doesn't help the problem.

This is one of the things about D that's seriously WAT-worthy.


T

-- 
If it breaks, you get to keep both pieces. -- Software disclaimer notice

On Monday, 19 August 2013 at 17:45:44 UTC, H. S. Teoh wrote:
> On Mon, Aug 19, 2013 at 07:34:38PM +0200, Dicebot wrote:
>> On Monday, 19 August 2013 at 17:22:26 UTC, H. S. Teoh wrote:
>> >What I'd like to know, is how all of these proposals address the
>> >fundamental differences between "symbol tuples" (compile-time
>> >construct)
>> 
>> Those are not symbol tuples. For example, `int` is not a symbol.
>> http://dlang.org/template.html#Symbol - only things that have
>> identifiers and template instances are symbols.
>
> Well, OK, whatever they're supposed to be called. Compiler-tuples, or
> expression tuples, or whatever.

Well, technically they are compile-time tuples of stuff. Yep, that bad :) They don't have a good name because they don't have a good meaning, only behavior.

> See, part of the problem is that they
> just don't have any good name that correctly conveys what they are.
> Calling them "tuple" only adds to the confusion because of the
> conflation with std.range.Tuple.

std.typecons.Tuple ;) I have noticed it is not the first time you want to move it to std.range ;)

Well, you see, they are really both tuples. That is also the problem - call them whatever you want but they still both will be tuples. Compile-time tuple and run-time tuple, that is it (and I was recently surprised to learn that even their implementations are deeply tied).

I don't think simply changing a name to something irrelevant will magically solve confusion, it is feature in general that need clear re-definition in all relevant documentation. "Tuple" entry on dlang.org does not mention even half of the truth about it...

On Monday, 19 August 2013 at 17:22:26 UTC, H. S. Teoh wrote:
> What I'd like to know, is how all of these proposals address the
> fundamental differences between "symbol tuples" (compile-time construct) and std.range.Tuple (runtime construct). As far as I can tell, people are still confusing the two, and it's really not helping. Before we solve this, any syntax suggestion seems more like a mortician's work than a real solution.

As far as I can tell, when everyone talks about tuple syntax, they are talking about run-time tuples. That's definitely what I'm talking about whenever I mention tuple syntax, as I don't think it would be a good thing to use it for both run-time and compile-time tuples (and I don't really consider the latter tuples).

Bearophile has mentioned a couple times that we could use the tuple syntax for both, and bring about a unification of these two tuple types. I don't like this, as they're both very different entities, and don't really have any relation to each-other whatsoever.

I think the best course of action is to keep TypeTuples as is (and possibly provide a new name for them, underdocumenting or outright deprecating the old name), and introduce the new syntax for run-time tuples.

Speaking of new names for TypeTuple, I don't know if this was mentioned already, but what about "Variadic Lists"?

On Monday, 19 August 2013 at 17:57:45 UTC, Meta wrote:
> As far as I can tell, when everyone talks about tuple syntax, they are talking about run-time tuples. That's definitely what I'm talking about whenever I mention tuple syntax, as I don't think it would be a good thing to use it for both run-time and compile-time tuples (and I don't really consider the latter tuples).

No. I speak exclusively about native syntax for compile-time tuples and stand by the point that run-time tuples are mostly fine as-is and should not be touched at all.

On 8/19/13 10:54 AM, Dicebot wrote:
> On Monday, 19 August 2013 at 17:45:44 UTC, H. S. Teoh wrote:
>> On Mon, Aug 19, 2013 at 07:34:38PM +0200, Dicebot wrote:
>>> On Monday, 19 August 2013 at 17:22:26 UTC, H. S. Teoh wrote:
>>> >What I'd like to know, is how all of these proposals address >the
>>> >fundamental differences between "symbol tuples" (compile-time
>>> >construct)
>>>
>>> Those are not symbol tuples. For example, `int` is not a symbol.
>>> http://dlang.org/template.html#Symbol - only things that have
>>> identifiers and template instances are symbols.
>>
>> Well, OK, whatever they're supposed to be called. Compiler-tuples, or
>> expression tuples, or whatever.
>
> Well, technically they are compile-time tuples of stuff.

I'd call them alias tuples.

Andrei

On Monday, 19 August 2013 at 18:11:34 UTC, Andrei Alexandrescu wrote:
> I'd call them alias tuples.

Because we don't have strict definition of alias too? :)

Actually, I have forgot again that built-in tuples are not always compile-time. They can be used to declare run-time entities with tuple syntax too, that was exactly what was abused in std.typecons.Tuple implementation.

As I have already said, it is hard to name something that does not have clear semantics and is essentially just random collection of behavior.

Wyatt:

> The octothorpe _is_ much better than the t simply in terms of readability, though, even more than q{} or t{}, I have concerns about its ability to be found with an ordinary search engine by an ordinary user.  Have you tried looking for documentation on weird operators with a search engine lately?  They don't exactly take to it well. :/ (cf. Perl's <=>)

I think none of the suggested tuple syntaxes are well searchable on Google, but the "tuple()" syntax.

But in the Haskell world the Hoogle direct&reverse search engine supports symbols too (but it's mostly used to search for functions given their signature, I think so far this is something not present in the D world):

http://www.haskell.org/hoogle/?hoogle=%3D%3E


> I even don't like how the unicode version of that one looks;

It was just an idea, to show what I meant by representing the bananas with Unicode glyphs. The actual choice of glyphs is not an urgent choice :-) The idea comes from the now dead Fortress language.


> I feel weird admitting this, but if we can't use some manner of bare brace, I think I'd rather have tup(), tup[], tup{} (or even tuple() et al) as a prefix over any single character.

At the moment I prefer #() syntax, with ? for single wildcards. It's better than tup{} or t{} because the # symbol pops out more visually. tuple() syntax is long, but it's readable, and perhaps partially backwards compatible.


> Can't make it a single underscore? Question mark works best then, IMO.  It isn't as burdened with meanings elsewhere (sure there's ternary and possibly-match in regex, but...have I forgotten something?)

The ? of regexes is inside strings, so I think it causes no problems. And I think it doesn't clash with the ternary operator because before the ? wildcard you put a comma, a semicolon or a #(.


>> Assuming the "..." syntax for unpacking, it would be useful to name the captured tail. For example, you could unpack #(1, 3, #(4, 6)) into #(a, b, x...), where a = 1, b = 3, x = #(4, 6). Similarly, #(head, rest...) results in head = 1, rest = #(2, #(4, 6)). I think this would be very useful.

In Haskell there is also a way to give a name to the whole tuple and names to its parts:

Prelude> let t1 = (10, 20)
Prelude> let a@(b, c) = t1
Prelude> a
(10,20)
Prelude> b
10
Prelude> c
20

-------------------------

Meta:

> Bearophile has mentioned a couple times that we could use the tuple syntax for both, and bring about a unification of these two tuple types. I don't like this, as they're both very different entities, and don't really have any relation to each-other whatsoever.

Mine was an idea, but if it turns out to be a bad idea, then let's ignore it.

Bye,
bearophile

On Monday, 19 August 2013 at 18:19:11 UTC, bearophile wrote:
> Mine was an idea, but if it turns out to be a bad idea, then let's ignore it.

I was initially completely opposed against it but now that I have realized built-in ones do some run-time magic too, it does not sound _that_ crazy anymore.

Seriously, if current std.typecons.Tuple is implemented in terms if built-in tuple, than it sounds like only think built-in ones are lacking is ABI. Define it and using one single tuple syntax / implementation for everything becomes real.

I mean:

import std.typecons;
import std.typetuple;

void main()
{
	alias TT = TypeTuple!(int, string);
	
        // moar confusion for gods of confusion!
        // what is the difference between twoVars1 and twoVars2 other than latter is wrapped into struct and has ABI?
	TT twoVars1;
	Tuple!(int, string) twoVars2;
}

On Mon, Aug 19, 2013 at 08:10:38PM +0200, Dicebot wrote:
> On Monday, 19 August 2013 at 17:57:45 UTC, Meta wrote:
> >As far as I can tell, when everyone talks about tuple syntax, they are talking about run-time tuples. That's definitely what I'm talking about whenever I mention tuple syntax, as I don't think it would be a good thing to use it for both run-time and compile-time tuples (and I don't really consider the latter tuples).
> 
> No. I speak exclusively about native syntax for compile-time tuples and stand by the point that run-time tuples are mostly fine as-is and should not be touched at all.

Case in point. :)

So we're actually talking at cross purposes here. Bearophile & Meta et al want native syntax for *runtime* tuples (i.e. std.typecons.Tuple -- sorry for the mixup with std.range in my earlier posts), but you're talking about native syntax for alias tuples (aka TypeTuples). Two completely different things.

I agree that we shouldn't be making built-in syntax for a library type. If anything, any dedicated syntax should be reserved for alias tuples (aka std.typetuple.Typetuple). Or, at the very least, rename TypeTuple to AliasTuple.

Conflating these two concepts has led to endless confusion, which is why I insisted on addressing this issue before we even begin to talk about syntax. Otherwise we're going nowhere.


T

-- 
Let's not fight disease by killing the patient. -- Sean 'Shaleh' Perry