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

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

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

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

== 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

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

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

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

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;
>