September 23, 2012 Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | On Sunday, 23 September 2012 at 22:55:33 UTC, Timon Gehr wrote:
> I believe it is currently left-to-right for D, in all kinds of
> expressions, but DMD does not implement it yet.
Yeah, I thought it was already defined.
|
September 23, 2012 Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On 09/24/2012 12:57 AM, Andrei Alexandrescu wrote: > On 9/23/12 6:42 PM, Timon Gehr wrote: >> That is because it does not base the discussion on the right >> limitations of built-in tuples: Actually that is mostly unrelated to the comma operator. Apologies. >> >> auto (a,b) = (1,"3"); >> (auto a, string b) = (1, "3"); > > I meant to mention that but forgot. The interesting thing about this is > that, if we decide it's the main issue with today's tuples, we pull > Kenji's patch and close the case. > Imho, it certainly is the main issue. > ... >> - We already use the name 'tuple'. I'd suggest renaming that to >> 'sequence' or similar. template Seq(T...){ alias T Seq; } > > Then what are the "old" tuples? > Instances of TypeTuples, eg: template Seq(T...){ alias T Seq; } Seq!(int, double) foo(){ } => "Error: functions cannot return a tuple" >> - The empty tuple can well be (), just like 'Seq!()' works without >> issues (it is an expression that is also a type). What is wrong with >> it? > > There's already intensive use of parens in D. I predict there's going to > be big trouble with "()" even assuming it's not technical ambiguous, Well, (,) cannot help with that. > for > example a lambda that returns an empty tuple would be "()() {...}" and > all that jazz. Well, it would be ()=>() or delegate()()=>(), but is it even reasonable to use the second form? > >> - How do we expand a sequence into a tuple? >> => (Seq!(1,2,3),) > > I think we're discussing different things - the above seems to deal with > expression/alias tuples. DIP19 discusses strictly runtime value tuples. > I am discussing the interplay of the two features. Sequences are auto-expanded in all contexts where it makes sense (except if they happen to be the second argument to a comma expression, then they are not, but I assume that is a bug.) I expect the following to be equivalent: (Seq!(1,2,3),) and (1,2,3) >> - What is the calling convention used for passing built-in tuples to >> and from functions? > > I don't know. The current approach with .expand is nothing special - as > if the programmer wrote the expansion by hand. > Not sure we are on the same page. I meant the calling convention at the ABI level. >> - As tuples are built-in, expansion can be shorter than '.expand'. >> foo(1, tup..., 3); ? > > I find that sugar gratuitous. > You find built-in tuples gratuitous in general. :o) Anyway, it certainly is not necessary. >> - Template tuple parameters? This would work, but... >> template Tuple((T...,)){ alias (T,) Tuple; } >> >> void bar(T,(U...,),V...)(T delegate(U) dg, V args){ ... } >> void foo(T,(U...,),(V...,))(T delegate(U) dg, V args){ >> bar!(T,Tuple!U,V)(dg, args); >> } // U and V can be passed separately >> >> - Named tuple fields? >> >> (int x, int y) tuple = (1,2); >> >> swap(tuple.x, tuple.y); > > I kinda got lost around all that. > I assume named tuple fields are not a problem? Other than that, I raised the issue of how to match and destructure tuple types in template parameter lists. And came up with the following proposal, which I do not like. template Foo((U...,)){ alias (U,) Foo; } void main(){ (int, double) x; Foo!(typeof(x)) y; static assert(is(typeof(x)==typeof(y))); } |
September 23, 2012 Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples | ||||
---|---|---|---|---|
| ||||
Posted in reply to deadalnix | On 09/24/2012 01:08 AM, deadalnix wrote:
> Le 24/09/2012 00:48, Andrei Alexandrescu a écrit :
>> This notion a lot of trouble with it; I think it's safe to abandon it
>> entirely.
>>
>> Once a one-element tuple becomes equivalent to the actual item, there's
>> an explosion of trouble and special cases in the language and in code
>> that uses it. For example, divide and conquer code that manipulates
>> tuples and takes t[0 .. $/2] and t[$/2+1 .. $] would suddenly get to
>> cases in which the slices are no longer tuples, and so on. And that's
>> only the beginning.
>>
>
> This is a very weak point. In most cases, divide an conquer with tuple
> don't even make sense.
>
>> Also, having no integrated notion of a zero-element tuple would again
>> mess with the algebra as much as the absence of 0 would hurt numbers.
>> It's just troublesome.
>>
>> I appreciate the attraction of this idea, but again I think it's safe to
>> just not even discuss it.
>>
>
> I'm not sure I want to answer that, so I wont.
I agree with Andrei. Single element tuples need to support the same
operations as tuples of other arities do.
|
September 23, 2012 Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | Andrei Alexandrescu:
> The interesting thing about this is that, if we decide it's the main issue with today's tuples, we pull Kenji's patch and close the case.
As I have tried to explain in my precedent post, Kenji's patch covers about 1/4 of the most important use cases.
Bye,
bearophile
|
September 23, 2012 Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | Timon Gehr: > cases already introduce their own scopes in D, Thank you, I didn't remember this. > but switch cannot be extended well to serve such use cases. Please explain, as I am not able to see the problems. I have discussed that topic a little here: http://d.puremagic.com/issues/show_bug.cgi?id=596 Bye, bearophile |
September 23, 2012 Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | On 09/24/2012 01:36 AM, bearophile wrote: > Timon Gehr: > >> cases already introduce their own scopes in D, > > Thank you, I didn't remember this. > > >> but switch cannot be extended well to serve such use cases. > > Please explain, as I am not able to see the problems. > Switch is syntax sugar for jump tables. An adequate pattern matching construct would not require explicit control flow statements, and it would be an expression of arbitrary type. > I have discussed that topic a little here: > http://d.puremagic.com/issues/show_bug.cgi?id=596 > > Bye, > bearophile |
September 23, 2012 Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | Timon Gehr:
> Switch is syntax sugar for jump tables. An adequate pattern matching
> construct would not require explicit control flow statements, and it would be an expression of arbitrary type.
Introducing a good pattern matching syntax in D requires the introduction of a good amount of complexity. This idea was discussed few times in past.
D switches also work on strings, wstrings, dstrings, so the idea of extending them to work on small array is not too much different.
I think that switching on structs, and tuples with auto-assignment of variables for tuple fields, is enough to extend the usefulness of D switches significantly, while it introduces no new keywords, and not a lot of complexity for both the compiler and the programmer that has to learn D language.
Bye,
bearophile
|
September 23, 2012 Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | Le 24/09/2012 01:28, Timon Gehr a écrit :
> I agree with Andrei. Single element tuples need to support the same
> operations as tuples of other arities do.
Obviously it should. The whole point is that you can implicitly cast a 1 element tuple into the element and vice versa.
like :
(int) a = (3); // a is a tuple of 1 element.
int b = a; // Implicit tuple unpack.
a = b; // Implicit tuple packing.
|
September 24, 2012 Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | Le 24/09/2012 01:23, Timon Gehr a écrit : > I assume named tuple fields are not a problem? I'm not sure it is really usefull. > Other than that, I raised the issue of how to match and destructure > tuple types in template parameter lists. And came up with the following > proposal, which I do not like. > > template Foo((U...,)){ alias (U,) Foo; } > > void main(){ > (int, double) x; > Foo!(typeof(x)) y; > static assert(is(typeof(x)==typeof(y))); > } > The template syntax seems weird. Why do you want Foo((U...,)) when Foo(U) could do it ? |
September 24, 2012 Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | Le 24/09/2012 01:34, bearophile a écrit :
> Andrei Alexandrescu:
>
>> The interesting thing about this is that, if we decide it's the main
>> issue with today's tuples, we pull Kenji's patch and close the case.
>
> As I have tried to explain in my precedent post, Kenji's patch covers
> about 1/4 of the most important use cases.
>
It would be great if we stopped to base design reflection on actual implementations we have somewhere.
|
Copyright © 1999-2021 by the D Language Foundation