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