retard <re@tard.com.invalid> wrote:

>>> Why do tuple fields need a name?
>>
>> They don't always need, but oftentimes names are better than numeric
>> constants.
>
> If some compile time voodoo isn't used, the names have an effect on the
> performance (runtime lookups).

What? You really think structs/tuples are implemented like
Variant[string]?

foo.bar => *(&foo + bar.offsetof), where offsetof is known at
compiletime. It doesn't get faster than that.

-- 
Simen

On 10/7/10 10:22 CDT, Simen kjaeraas wrote:
> retard <re@tard.com.invalid> wrote:
>
>>>> Why do tuple fields need a name?
>>>
>>> They don't always need, but oftentimes names are better than numeric
>>> constants.
>>
>> If some compile time voodoo isn't used, the names have an effect on the
>> performance (runtime lookups).
>
> What? You really think structs/tuples are implemented like
> Variant[string]?
>
> foo.bar => *(&foo + bar.offsetof), where offsetof is known at
> compiletime. It doesn't get faster than that.
>

Yah, this is D dammit :o).

Andrei

Thu, 07 Oct 2010 17:22:08 +0200, Simen kjaeraas wrote:

> retard <re@tard.com.invalid> wrote:
> 
>>>> Why do tuple fields need a name?
>>>
>>> They don't always need, but oftentimes names are better than numeric constants.
>>
>> If some compile time voodoo isn't used, the names have an effect on the performance (runtime lookups).
> 
> What? You really think structs/tuples are implemented like Variant[string]?
> 
> foo.bar => *(&foo + bar.offsetof), where offsetof is known at compiletime. It doesn't get faster than that.

There are several conflicting concepts at stake here. I guess the nominative typing is quite clear -- the type name fully dictates the physical and logical form of the data.

But structural typing can be implemented in several ways. I use the name 'record' for tuples with field names. This notation doesn't necessarily define any physical order of fields in the memory. When you bring an aggregate from the tuple world to the struct world, you have to lock down some physical layout for the data.

If you don't have first class tuple constructors and define them with a template, that's unfortunately not structural typing. The D's structs might use the copying semantics from structural typing, but it's a weird hybrid type, actually. Just like the tuples aren't real tuples. Field names break the definition. Type tuples break it, too.

On 2010-10-07 02:04:35 -0400, Walter Bright <newshound2@digitalmars.com> said:

> There have been a couple of looong threads about tuples:
> 
> http://www.digitalmars.com/d/archives/digitalmars/D/Reddit_why_aren_t_people_using_D_93528.html

http://www.digitalmars.com/d/archives/digitalmars/D/Should_the_comma_operator_be_removed_in_D2_101321.html

A 
> 
> lot of it foundered on what the syntax for tuple literals should be. The top of the list is simply enclosing them in ( ). The problem with this is
> 
>   (expression)
> 
> Is that a parenthesized expression, or a tuple? This really matters, since (e)[0] means very different things for the two.

> Finally, I got to thinking, why not just make it a special case:
> 
> 
>   ( ) == tuple
>   (a) == parenthesized expression
>   (a,b) == tuple
>   (a,b,c) == tuple
>   (a,b,c,d) == tuple
> 
> etc.

Seems good. I know some people have complained about the lack of a semantic foundation, but my understanding is that this is simply a syntax to define the same kind of tuple as you get with variadic template arguments or variables made from types defined as variadic template arguments. The semantic foundation is already there and in use with variadic templates, it just lacks a few features (literals and the ability to be a return type).

If this can be used in place of both Tuple!() and TypeTuple!() defined in Phobos, then it'll be great as we'll no longer need to have two distinct tuple concepts: one in the language and another Tuple!() wrapper that sits top of it just so we can return a tuple from a function.

For the syntax, I'd like to second Juanjo's suggestion to mimic Python for the one-element tuple:

	(a,) == tuple

And Don's extension of that suggestion that it always accept a trailing comma like enums and array literals:

	(a,b,) == tuple
	(a,b,c,) == tuple


-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

retard <re@tard.com.invalid> wrote:

> If you don't have first class tuple constructors and define them with a
> template, that's unfortunately not structural typing.

Might I inquire as to why?

As far as I can see, one can regard a structural type as a set of types,
fields, if you will. Each element of this set has some properties, which
would have to be equal to those of an element of a similar set in an
equal type. That is, (int, string) may be equal to (string, int) if one
considers index not to be one of those properties.

Some structural type systems will consider names part of those properties,
leading (string a, int b) to be equivalent to (int b, string a), if, as
before, index is not an interesting property.

By choosing opposite in these choices (index is important, name is not),
I cannot see that the premise of a structural type system is broken. In
this system, (int b, string a) != (string a, int b), and
(string a, int b) == (string b, int a).

Either of these choices can be implemented in D (the latter I have
implemented), so I cannot quite see where you are going with this.

> The D's structs
> might use the copying semantics from structural typing, but it's a weird
> hybrid type, actually.

In this I agree. Well, given that in D a struct name in D would be unique
(bar linker fuckups), I would argue it is nominative.


-- 
Simen

Ellery Newcomer wrote:
> I might be missing something, but how does this proposal get around the ambiguity in
> 
> (a,b,c)[0]
> 
> ?
> 
> Currently, it's valid C syntax and valid D syntax. In your proposal it would be valid tuple syntax too.

As has been proposed frequently, the , operator would have to be dispensed with.

On Thu, 07 Oct 2010 13:52:56 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

> Ellery Newcomer wrote:
>> I might be missing something, but how does this proposal get around the ambiguity in
>>  (a,b,c)[0]
>>  ?
>>  Currently, it's valid C syntax and valid D syntax. In your proposal it would be valid tuple syntax too.
>
> As has been proposed frequently, the , operator would have to be dispensed with.

I think what Ellery is alluding to is it breaks the rule that things that are valid C syntax do the same thing that happens in C.  Of course we've broken this rule a few times.

-Steve

Thu, 07 Oct 2010 19:12:45 +0200, Simen kjaeraas wrote:

> retard <re@tard.com.invalid> wrote:
> 
>> If you don't have first class tuple constructors and define them with a template, that's unfortunately not structural typing.
> 
> Might I inquire as to why?

I see these "tuples" defined with a template merely as structs in disguise. They don't cover all the cases where built-in first class tuples can be used.

On 10/7/10 13:44 CDT, retard wrote:
> Thu, 07 Oct 2010 19:12:45 +0200, Simen kjaeraas wrote:
>
>> retard<re@tard.com.invalid>  wrote:
>>
>>> If you don't have first class tuple constructors and define them with a
>>> template, that's unfortunately not structural typing.
>>
>> Might I inquire as to why?
>
> I see these "tuples" defined with a template merely as structs in
> disguise. They don't cover all the cases where built-in first class
> tuples can be used.

Could you please take the time to put together a list of requirements? That would be great for either making Tuple better or for improving the language.

Andrei

Thu, 07 Oct 2010 13:48:31 -0500, Andrei Alexandrescu wrote:

> On 10/7/10 13:44 CDT, retard wrote:
>> Thu, 07 Oct 2010 19:12:45 +0200, Simen kjaeraas wrote:
>>
>>> retard<re@tard.com.invalid>  wrote:
>>>
>>>> If you don't have first class tuple constructors and define them with a template, that's unfortunately not structural typing.
>>>
>>> Might I inquire as to why?
>>
>> I see these "tuples" defined with a template merely as structs in disguise. They don't cover all the cases where built-in first class tuples can be used.
> 
> Could you please take the time to put together a list of requirements? That would be great for either making Tuple better or for improving the language.

Sure, but I can't really promise to have to capacity to think about every possible case when we are discussing D. There are so many complex features! I think a more or less complete list can already be constructed from all past discussions here. The tuple issues come up every now and then.

FWIW, the library provided solution with syntactical support doesn't sound so bad now that I think about it. We just need to know, what we are trying to solve here. The bigger problems come up when overloading the same system with mixed value/type/alias tuples.