www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - tuple sumlimation

reply Kevin Bealer <kevinbealer gmail.com> writes:
Currently, Tuples are sublimated into argument lists.  What do people 
think of using an operator (say, *) to prevent this?  The reason I ask 
is that the current technique makes it hard to pass multiple tuples on 
the same function call.

I think it's not absolutely required; currently you can pass the tuple 
lengths, let the tuples melt together, and then split them with slicing.

Kevin
Feb 13 2007
next sibling parent Reiner Pope <xxxx xxx.xxx> writes:
Kevin Bealer wrote:
 Currently, Tuples are sublimated into argument lists.  What do people 
 think of using an operator (say, *) to prevent this?  The reason I ask 
 is that the current technique makes it hard to pass multiple tuples on 
 the same function call.
 
 I think it's not absolutely required; currently you can pass the tuple 
 lengths, let the tuples melt together, and then split them with slicing.
 
 Kevin
How about expressing tuples as arrays? I mean, that's what they act as, and the features they support are array features: length, indexing, and a long-winded form of concatenation. Explicitly using them as arrays also allows for code reuse with already-existing array manipulation functions/templates. So, regular tuples are just alias[], and type tuples could be typeid[] or even TypeInfo[]. You keep the old ... syntax (with implicit concatenation) and introduce a new one which supports alias[] and TypeInfo[] as template parameters. You could get the following (and equivalent forms for alias[]): void writefln(T...)(T t) {...} // old syntax void writefln2(TypeInfo[] T)(T t) {...} // new syntax -- no advantage here template Foo(T...) {...} template Bar(TypeInfo[] T) {...} template Baz(TypeInfo[] T, TypeInfo[] U) { Foo!(T, U); // implicit concatenation, so we don't break old behaviour Bar!(T, U); // error: no implicit concatenation in new behaviour Bar!(T); // ok Bar!(T ~ U); // explicit concatenation still allowed } template Bam(T...) { Foo!(T, T); // implicit concatenation, like before Bar!(T ~ T); // T is actually TypeInfo[], so concatenation syntax permitted Baz!(T, T); // No implicit concatenation } It shouldn't break existing code, but it should support nesting (by disallowing implicit concating), as well as more code reuse. Cheers, Reiner
Feb 13 2007
prev sibling next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Kevin Bealer wrote:
 Currently, Tuples are sublimated into argument lists.  What do people 
 think of using an operator (say, *) to prevent this?  The reason I ask 
 is that the current technique makes it hard to pass multiple tuples on 
 the same function call.
 
 I think it's not absolutely required; currently you can pass the tuple 
 lengths, let the tuples melt together, and then split them with slicing.
 
 Kevin
I think Walter and Andrei are very aware that the inability to make Tuples hierarchical is a hindrance to many kinds of algorithms. But definitely some way to make hierarchical tuples is a must. Lisp without nested lists is close to useless. The * type of syntax is used in Python to control expansion of tuples into arguments. Though I think it's kind of backwards from what you're saing -- func(*args) causes args to be passed as separate arguments, func(args) passes it as a single argument that is a tuple. Personally I think that makes more sense. Automatically expanding as the default is kind of odd. No other argument type modifies itself in funky ways when you pass it to a function. --bb
Feb 13 2007
next sibling parent "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:
 Kevin Bealer wrote:
 Currently, Tuples are sublimated into argument lists.  What do people 
 think of using an operator (say, *) to prevent this?  The reason I ask 
 is that the current technique makes it hard to pass multiple tuples on 
 the same function call.

 I think it's not absolutely required; currently you can pass the tuple 
 lengths, let the tuples melt together, and then split them with slicing.

 Kevin
I think Walter and Andrei are very aware that the inability to make Tuples hierarchical is a hindrance to many kinds of algorithms. But definitely some way to make hierarchical tuples is a must. Lisp without nested lists is close to useless.
It's funny this came up. It was only our last discussion that we talked about the issue. I compared the mistake of flattening tuples with that of flattening Perl function array arguments. Perl has suffered from it, and now has an alternative mechanism (reference) to deal with that; the plan is to turn D's semantics around while there is time. This is particularly important for the upcoming AST manipulation abilities. ASTs might be unified with tuples; if you flatten the tuples, they aren't trees anymore and you lose information, unless you plan to flatten them the Forth way :o).
 The * type of syntax is used in Python to control expansion of tuples 
 into arguments.  Though I think it's kind of backwards from what you're 
 saing -- func(*args) causes args to be passed as separate arguments, 
 func(args) passes it as a single argument that is a tuple.  Personally I 
 think that makes more sense.   Automatically expanding as the default is 
 kind of odd.  No other argument type modifies itself in funky ways when 
 you pass it to a function.
Agreed. Andrei
Feb 13 2007
prev sibling parent Kevin Bealer <kevinbealer gmail.com> writes:
== Quote from Bill Baxter (dnewsgroup billbaxter.com)'s article
 Kevin Bealer wrote:
 Currently, Tuples are sublimated into argument lists.  What do people
 think of using an operator (say, *) to prevent this?  The reason I ask
 is that the current technique makes it hard to pass multiple tuples on
 the same function call.

 I think it's not absolutely required; currently you can pass the tuple
 lengths, let the tuples melt together, and then split them with slicing.

 Kevin
I think Walter and Andrei are very aware that the inability to make Tuples hierarchical is a hindrance to many kinds of algorithms. But definitely some way to make hierarchical tuples is a must. Lisp without nested lists is close to useless. The * type of syntax is used in Python to control expansion of tuples into arguments. Though I think it's kind of backwards from what you're saing -- func(*args) causes args to be passed as separate arguments, func(args) passes it as a single argument that is a tuple. Personally I think that makes more sense. Automatically expanding as the default is kind of odd. No other argument type modifies itself in funky ways when you pass it to a function. --bb
Yeah, this is what I had in mind but somehow I wrote a post that implied the opposite. The python way looks better if its okay to with break the current tuple-using code. If backward compatibility is needed, "&" could be used by analogy, to do the opposite, i.e. ask for a tuple to stay 'wrapped up'. This seems wrong though because taking a pointer to a tuple should be possible. If it's needed to work with pointers to tuples, maybe a different syntax could be found. Kevin
Feb 14 2007
prev sibling parent reply Pragma <ericanderton yahoo.removeme.com> writes:
Kevin Bealer wrote:
 Currently, Tuples are sublimated into argument lists.  What do people 
 think of using an operator (say, *) to prevent this?  The reason I ask 
 is that the current technique makes it hard to pass multiple tuples on 
 the same function call.
 
 I think it's not absolutely required; currently you can pass the tuple 
 lengths, let the tuples melt together, and then split them with slicing.
 
 Kevin
The only workaround I have used for this is to turn a tuple into a compile-time "struct" to pass it to another template: import std.metastrings; // use whatever name you want, and add whatever 'member' aliases you need here template Struct(V...){ alias V Values; } template MyExample(alias Arr1,alias Arr2){ pragma(msg,Format!("%s",Arr1.Values[0])); pragma(msg,Format!("%s",Arr2.Values[0])); } alias MyExample!(Struct!(1,2,3),Struct!("x","y","z")) Foobar; -- - EricAnderton at yahoo
Feb 16 2007
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Pragma wrote:
 Kevin Bealer wrote:
 Currently, Tuples are sublimated into argument lists.  What do people 
 think of using an operator (say, *) to prevent this?  The reason I ask 
 is that the current technique makes it hard to pass multiple tuples on 
 the same function call.

 I think it's not absolutely required; currently you can pass the tuple 
 lengths, let the tuples melt together, and then split them with slicing.

 Kevin
The only workaround I have used for this is to turn a tuple into a compile-time "struct" to pass it to another template: import std.metastrings; // use whatever name you want, and add whatever 'member' aliases you need here template Struct(V...){ alias V Values; } template MyExample(alias Arr1,alias Arr2){ pragma(msg,Format!("%s",Arr1.Values[0])); pragma(msg,Format!("%s",Arr2.Values[0])); } alias MyExample!(Struct!(1,2,3),Struct!("x","y","z")) Foobar;
Nice idea! But do you mean struct Struct(V...) { alias V Values; } ??? Otherwise Struct is just making a Tuple. Or is the trick the fact that you pass it as an alias to the template that needs two Tuples? --bb
Feb 16 2007
parent Pragma <ericanderton yahoo.removeme.com> writes:
Bill Baxter wrote:
 Pragma wrote:
 Kevin Bealer wrote:
 Currently, Tuples are sublimated into argument lists.  What do people 
 think of using an operator (say, *) to prevent this?  The reason I 
 ask is that the current technique makes it hard to pass multiple 
 tuples on the same function call.

 I think it's not absolutely required; currently you can pass the 
 tuple lengths, let the tuples melt together, and then split them with 
 slicing.

 Kevin
The only workaround I have used for this is to turn a tuple into a compile-time "struct" to pass it to another template: import std.metastrings; // use whatever name you want, and add whatever 'member' aliases you need here template Struct(V...){ alias V Values; } template MyExample(alias Arr1,alias Arr2){ pragma(msg,Format!("%s",Arr1.Values[0])); pragma(msg,Format!("%s",Arr2.Values[0])); } alias MyExample!(Struct!(1,2,3),Struct!("x","y","z")) Foobar;
Nice idea! But do you mean struct Struct(V...) { alias V Values; } ??? Otherwise Struct is just making a Tuple. Or is the trick the fact that you pass it as an alias to the template that needs two Tuples?
Yes. The trick is indeed the use of "alias"; it allows you to pass the template's namespace just as you would any other instanced type. AFAIK, you can't just pass a tuple to an alias param, so you need to wrap it first. -- - EricAnderton at yahoo
Feb 16 2007
prev sibling parent Kevin Bealer <kevinbealer gmail.com> writes:
Thanks - I didn't realize you could do this.

Kevin

Pragma wrote:
 Kevin Bealer wrote:
 Currently, Tuples are sublimated into argument lists.  What do people 
 think of using an operator (say, *) to prevent this?  The reason I ask 
 is that the current technique makes it hard to pass multiple tuples on 
 the same function call.

 I think it's not absolutely required; currently you can pass the tuple 
 lengths, let the tuples melt together, and then split them with slicing.

 Kevin
The only workaround I have used for this is to turn a tuple into a compile-time "struct" to pass it to another template: import std.metastrings; // use whatever name you want, and add whatever 'member' aliases you need here template Struct(V...){ alias V Values; } template MyExample(alias Arr1,alias Arr2){ pragma(msg,Format!("%s",Arr1.Values[0])); pragma(msg,Format!("%s",Arr2.Values[0])); } alias MyExample!(Struct!(1,2,3),Struct!("x","y","z")) Foobar;
Feb 16 2007