Steve Yegge's rant on The Next Big Language

[Bill Baxter]

BCS wrote:
> Jarrett Billingsley wrote:
>>
>>
>> Except for the typing system (though it could certainly get there), 
>> the absolute lack of tools, and missing about half of the Kitchen Sink 
>> points ;) 
> 
> Half?, more like one or two hard misses and a few more close calls.
> 
> I can kill one close calls:
> 
>  >4 Destructuring bind (e.g. x, y = returnTwoValues())
> 
> If I'm reading it right this does that, and nicely:

Uh... no.  Sort of does it, yes.  Nicely? no.

>     bar(i,j)(k,l);

The winning solution should use the syntax
    i,j = bar(k,l);

And should also work in situations like
    // swap i and j
    i,j = j,i;

And should at least allow bar to be implemented like:

SetT!(int,int) bar(int i, int j)
{
    return SetT(i,j);
}

With a little tweaking of the way Tuples are handled, I think tuples 
could be made to satisfy this Kitchen Sink requirement.

Tuple!(int,int) bar(int i, int j)
{
    return Tuple!(i,j);
}

You can make a tuple from a struct with tupleof.  So value tuples are in 
a way just anonymous structs.  You can return a struct from a function. 
  So why not a value tuple?  Given that, plus a new rule that lets you 
assign a value tuple to a comma separated list (or alias tuple?), you'd 
be there.  These sorts of things seem like the direction Tuples are 
headed, taken to their logical conclusions.

If that happens I think maybe it's time for Tuple! to get a first class 
syntax.  Something on par with [a,b,c] for lists.  (a,b,c) would be 
great if that could be made to work.  If not, maybe !(a,b,c).  This 
would be nice to be able to write:

(int,int) bar(int i, int j)
{
    return (i,j);
}

x,y = bar(1,2);

--bb