www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: Tuple literal syntax

reply Kagamin <spam here.lot> writes:
Andrei Alexandrescu Wrote:


 struct Coord
 {
      int x, y, z;
 }
 
 one iota typesafer than
 
 alias Tuple!(int, "x", int, "y", int, "z") Coord;



Is there a real need for an alternative way to declare structs?
Oct 07 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/7/10 10:13 CDT, Kagamin wrote:

 Andrei Alexandrescu Wrote:


 struct Coord
 {
       int x, y, z;
 }

 one iota typesafer than

 alias Tuple!(int, "x", int, "y", int, "z") Coord;



 Is there a real need for an alternative way to declare structs?



Yes.

Andrei
Oct 07 2010
next sibling parent reply Stephan Soller <stephan.soller helionweb.de> writes:
On 07.10.2010 17:36, Andrei Alexandrescu wrote:

 On 10/7/10 10:13 CDT, Kagamin wrote:

 Andrei Alexandrescu Wrote:


 struct Coord
 {
 int x, y, z;
 }

 one iota typesafer than

 alias Tuple!(int, "x", int, "y", int, "z") Coord;



 Is there a real need for an alternative way to declare structs?



 Yes.

 Andrei



I agree but I also don't agree. I like the possibility to return 
multiple values (quite handy in Ruby, PHP and other languages) and 
therefore we need language constructs to group multiple values and 
ungroup them again.

However as soon as these fields are named it looks to me like an 
ordinary structure. So why not just create something like an "anonymous 
structure literal" that behaves to structures like anonymous functions 
(or delegates) to functions?

This would look a lot more consistent to me than playing around with 
different kinds of tuples. However I'm not sure about the details (e.g. 
how would such structures handle type or alias contents).

Happy programming
Stephan
Oct 10 2010
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Denis Koroskin:


 I don't mind having Tuple in a library, as long as I'm not insisted in  
 using it *and* it doesn't affect other language features.



More modern module-based languages as D are not like C. If they want some
success they develop a community of programmers that share modules. You don't
program in a vacuum any more. This means that if Tuple is appreciated and used
by the community, then you will often use modules (including frequently stuff
from Phobos2) written by other people that expect tuples as input values or
that return tuples as outputs and so on. So if tuples have success, you will
probably need to use them in your code too, they become an idiom of the
language almost as they are built-ins, this is also why it's better to give
them a good syntax.

Multiple return values have the disadvantage that sometimes your don't exactly
remember what each value is, but they are handy, and overall they are an
improvement over C-style single return values. In a recent post I've shown why
they may also help avoid some bugs compared to "out" arguments.

Bye,
bearophile
Oct 10 2010
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Simen kjaeraas:


 Perhaps it would be possible to augment struct static initializers for
 this purpose?
 
 { int a; string b } foo( ) {
      return { 1, "text" };
 }



What kind of tuple unpacking syntax do you suggest for this? (I think at the
moment the unpacking syntax is more important than the literals one).

Bye,
bearophile
Oct 10 2010
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/10/10 9:00 CDT, Denis Koroskin wrote:

 On Sun, 10 Oct 2010 17:39:52 +0400, Stephan Soller
 <stephan.soller helionweb.de> wrote:


 On 07.10.2010 17:36, Andrei Alexandrescu wrote:

 On 10/7/10 10:13 CDT, Kagamin wrote:

 Andrei Alexandrescu Wrote:


 struct Coord
 {
 int x, y, z;
 }

 one iota typesafer than

 alias Tuple!(int, "x", int, "y", int, "z") Coord;



 Is there a real need for an alternative way to declare structs?



 Yes.

 Andrei



 I agree but I also don't agree. I like the possibility to return
 multiple values (quite handy in Ruby, PHP and other languages) and
 therefore we need language constructs to group multiple values and
 ungroup them again.

 However as soon as these fields are named it looks to me like an
 ordinary structure. So why not just create something like an
 "anonymous structure literal" that behaves to structures like
 anonymous functions (or delegates) to functions?

 This would look a lot more consistent to me than playing around with
 different kinds of tuples. However I'm not sure about the details
 (e.g. how would such structures handle type or alias contents).

 Happy programming
 Stephan



 Exactly. To be honest, I see absolutely no reason to have yet another to
 declare structs, but some people have other preferences.
 I don't mind having Tuple in a library, as long as I'm not insisted in
 using it *and* it doesn't affect other language features.

 I mean, it's not even shorter to write

 alias Tuple!(int, "x", int, "y", int, "z") Coord;

 than

 struct Coord { int x; int y; int z; }



Tuples with named fields are restricted in a number of ways compared to 
structs. They are expandable, they have indexed fields, they offer no 
encapsulation, etc. Lambda structs would be rather unwieldy. I 
personally am fine with tuples.

Andrei
Oct 10 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei:


 Tuples with named fields are restricted in a number of ways compared to 
 structs. They are expandable, they have indexed fields, they offer no 
 encapsulation, etc. Lambda structs would be rather unwieldy. I 
 personally am fine with tuples.



Now the discussion is developing in a slower and more relaxed way. Have Walter
and you reached some partial conclusion on this subject? I am not asking for
the final words on this topic, because I probably  few further discussions will
be needed, but other people and I have already expressed several opinions and
ideas. I think that multiple return values and a nice clean packing & unpacking
syntax for tuples may be useful for D (especially if it can be used for
unpacking in foreach and function signatures too). And It's just syntax sugar,
yet I think a good syntax sugar for this is able to change the taste of the D
language, because if it's good and efficient, it will probably be used very
often, in normal Python code it's not hard to find one or more tuples every 3-8
lines of code, a normal Python module may contain a fifty tuple literals (often
just as "return x, y").

Bye,
bearophile
Oct 10 2010
parent bearophile <bearophileHUGS lycos.com> writes:
Philippe Sigaud:


 may I suggest to have a way to concatenate tuples?



I have implemented it, see enhancement request 4591

Bye,
bearophile
Oct 10 2010
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Sun, 10 Oct 2010 17:39:52 +0400, Stephan Soller  
<stephan.soller helionweb.de> wrote:


 On 07.10.2010 17:36, Andrei Alexandrescu wrote:

 On 10/7/10 10:13 CDT, Kagamin wrote:

 Andrei Alexandrescu Wrote:


 struct Coord
 {
 int x, y, z;
 }

 one iota typesafer than

 alias Tuple!(int, "x", int, "y", int, "z") Coord;



 Is there a real need for an alternative way to declare structs?



 Yes.

 Andrei



 I agree but I also don't agree. I like the possibility to return  
 multiple values (quite handy in Ruby, PHP and other languages) and  
 therefore we need language constructs to group multiple values and  
 ungroup them again.

 However as soon as these fields are named it looks to me like an  
 ordinary structure. So why not just create something like an "anonymous  
 structure literal" that behaves to structures like anonymous functions  
 (or delegates) to functions?

 This would look a lot more consistent to me than playing around with  
 different kinds of tuples. However I'm not sure about the details (e.g.  
 how would such structures handle type or alias contents).

 Happy programming
 Stephan



Exactly. To be honest, I see absolutely no reason to have yet another to  
declare structs, but some people have other preferences.
I don't mind having Tuple in a library, as long as I'm not insisted in  
using it *and* it doesn't affect other language features.

I mean, it's not even shorter to write

alias Tuple!(int, "x", int, "y", int, "z") Coord;

than

struct Coord { int x; int y; int z; }
Oct 10 2010
prev sibling next sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Stephan Soller <stephan.soller helionweb.de> wrote:


 However as soon as these fields are named it looks to me like an  
 ordinary structure. So why not just create something like an "anonymous  
 structure literal" that behaves to structures like anonymous functions  
 (or delegates) to functions?



Perhaps it would be possible to augment struct static initializers for
this purpose?

{ int a; string b } foo( ) {
     return { 1, "text" };
}

I'm not sure if there are problems with this syntax (it sorta looks
like a delegate, for one), so elucidation would be welcome.


-- 
Simen
Oct 10 2010
prev sibling next sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
bearophile <bearophileHUGS lycos.com> wrote:


 Simen kjaeraas:


 Perhaps it would be possible to augment struct static initializers for
 this purpose?

 { int a; string b } foo( ) {
      return { 1, "text" };
 }



 What kind of tuple unpacking syntax do you suggest for this? (I think at  
 the moment the unpacking syntax is more important than the literals one).



int a;
string b;
{ a, b } = foo( );

string s = "123456"
char c;
{ c, s... } = s;

I guess.

-- 
Simen
Oct 10 2010
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Sun, 10 Oct 2010 18:33:35 +0400, bearophile <bearophileHUGS lycos.com>  
wrote:


 Denis Koroskin:


 I don't mind having Tuple in a library, as long as I'm not insisted in
 using it *and* it doesn't affect other language features.



 More modern module-based languages as D are not like C. If they want  
 some success they develop a community of programmers that share modules.  
 You don't program in a vacuum any more. This means that if Tuple is  
 appreciated and used by the community, then you will often use modules  
 (including frequently stuff from Phobos2) written by other people that  
 expect tuples as input values or that return tuples as outputs and so  
 on. So if tuples have success, you will probably need to use them in  
 your code too, they become an idiom of the language almost as they are  
 built-ins, this is also why it's better to give them a good syntax.

 Multiple return values have the disadvantage that sometimes your don't  
 exactly remember what each value is, but they are handy, and overall  
 they are an improvement over C-style single return values. In a recent  
 post I've shown why they may also help avoid some bugs compared to "out"  
 arguments.

 Bye,
 bearophile



I was referring *only* to Tuple!(int, "foo", float, "bar") syntax. I'd  
love having proper tuples (Python-style or similar) support in D, and use  
it to the maximum. But Tuple!? Meh.
Oct 10 2010
prev sibling next sibling parent Philippe Sigaud <philippe.sigaud gmail.com> writes:
Whatever the conclusion on all this is, may I suggest to have a way to
concatenate tuples?

auto t1 = tuple(1, "a");                   // or (|1, "a"|) or {1,
"a"} or what have you.
auto t2 = tuple((int i, string s) { return i;});

auto result = t1 ~ t2;

result is a (int,string, int function(int,string)) tuple.

Ideally, you should also be able to add any value before or after a tuple.

auto result2 = 3.1415 ~ result;

This is easily added to std.typecons.Tuple with opBinary!"~".
Oct 10 2010
prev sibling parent Philippe Sigaud <philippe.sigaud gmail.com> writes:
On Sun, Oct 10, 2010 at 23:05, bearophile <bearophileHUGS lycos.com> wrote:

 Philippe Sigaud:


 may I suggest to have a way to concatenate tuples?



 I have implemented it, see enhancement request 4591



Cool, I'll have a look.

*does so*

Wow, much more complicated that what I had in mind. I totally forgot
about named fields.


Philippe
Oct 10 2010