If expr represents a tuple, we (Andrei and I) were thinking about the syntax:

    auto (a, b, c, d) = expr;

being equivalent to:

    auto t = expr; auto a = t[0]; auto b = t[1]; auto c = t[2 .. $];

You can also do this with arrays, such that:

    float[3] xyz;
    auto (x, y, z) = xyz;

The Lithpers among you will notice that this essentially provides a handy car,cdr shortcut for tuples and arrays:

    auto (car, cdr) = expr;

On Wed, 2010-10-06 at 23:08 -0700, Walter Bright wrote:
> If expr represents a tuple, we (Andrei and I) were thinking about the syntax:
> 
>      auto (a, b, c, d) = expr;
> 
> being equivalent to:
> 
>      auto t = expr; auto a = t[0]; auto b = t[1]; auto c = t[2 .. $];
> 
> You can also do this with arrays, such that:
> 
>      float[3] xyz;
>      auto (x, y, z) = xyz;
> 
> The Lithpers among you will notice that this essentially provides a handy car,cdr shortcut for tuples and arrays:
> 
>      auto (car, cdr) = expr;


Python may be the best base to compare things to as tuple assignment has been in there for years.

Pythons choice is not a car/cdr approach but an exact match approach. so if t represents a tuple datum or a function returning a tuple:

        x = t

then x is a tuple -- remembering that variables are all just references to objects implemented via keys in a dictionary, and:

        a , b , c = t
or
        ( a , b , c ) = t

is tuple assignment where now t is required to be a tuple of length 3. cf.


        |> python
        Python 2.6.5 (r265:79063, Apr 16 2010, 13:57:41)
        [GCC 4.4.3] on linux2
        Type "help", "copyright", "credits" or "license" for more information.
        >>> t = ( 1 , 'fred' , 2.0 )
        >>> x = t
        >>> print x
        (1, 'fred', 2.0)
        >>> a , b , c = t
        >>> print a , b , c
        1 fred 2.0
        >>> a , b = t
        Traceback (most recent call last):
          File "<stdin>", line 1, in <module>
        ValueError: too many values to unpack
        >>> a , b , c , d = t
        Traceback (most recent call last):
          File "<stdin>", line 1, in <module>
        ValueError: need more than 3 values to unpack
        >>>


-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@russel.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Russel Winder wrote:
> Python may be the best base to compare things to as tuple assignment has
> been in there for years.
> 
> Pythons choice is not a car/cdr approach but an exact match approach.
> so if t represents a tuple datum or a function returning a tuple:
> 
>         x = t
> 
> then x is a tuple -- remembering that variables are all just references
> to objects implemented via keys in a dictionary, and:
> 
>         a , b , c = t
> or
>         ( a , b , c ) = t
> 
> is tuple assignment where now t is required to be a tuple of length 3.
> cf.

The first thought was to make it an exact match approach. Andrei thought that the car/cdr one was better, though, and I find it intuitively appealing, too. Perhaps Python missed an important use case?

Or perhaps the ambiguity as to whether the last item gets to be a value or another tuple is too much.

Russel Winder wrote:
> Python may be the best base to compare things to as tuple assignment has
> been in there for years.

Too segue this into the previous thread, how does Python treat (1)? Is it a floor wax or a dessert topping?

http://www.nbc.com/saturday-night-live/video/shimmer-floor-wax/1056743/

On Thu, 07 Oct 2010 10:43:18 +0400, Russel Winder <russel@russel.org.uk> wrote:

> On Wed, 2010-10-06 at 23:08 -0700, Walter Bright wrote:
>> If expr represents a tuple, we (Andrei and I) were thinking about the syntax:
>>
>>      auto (a, b, c, d) = expr;
>>
>> being equivalent to:
>>
>>      auto t = expr; auto a = t[0]; auto b = t[1]; auto c = t[2 .. $];
>>
>> You can also do this with arrays, such that:
>>
>>      float[3] xyz;
>>      auto (x, y, z) = xyz;
>>
>> The Lithpers among you will notice that this essentially provides a handy
>> car,cdr shortcut for tuples and arrays:
>>
>>      auto (car, cdr) = expr;
>
>
> Python may be the best base to compare things to as tuple assignment has
> been in there for years.
>
> Pythons choice is not a car/cdr approach but an exact match approach.
> so if t represents a tuple datum or a function returning a tuple:
>
>         x = t
>
> then x is a tuple -- remembering that variables are all just references
> to objects implemented via keys in a dictionary, and:
>
>         a , b , c = t
> or
>         ( a , b , c ) = t
>
> is tuple assignment where now t is required to be a tuple of length 3.
> cf.
>
>
>         |> python
>         Python 2.6.5 (r265:79063, Apr 16 2010, 13:57:41)
>         [GCC 4.4.3] on linux2
>         Type "help", "copyright", "credits" or "license" for more information.
>         >>> t = ( 1 , 'fred' , 2.0 )
>         >>> x = t
>         >>> print x
>         (1, 'fred', 2.0)
>         >>> a , b , c = t
>         >>> print a , b , c
>         1 fred 2.0
>         >>> a , b = t
>         Traceback (most recent call last):
>           File "<stdin>", line 1, in <module>
>         ValueError: too many values to unpack
>         >>> a , b , c , d = t
>         Traceback (most recent call last):
>           File "<stdin>", line 1, in <module>
>         ValueError: need more than 3 values to unpack
>         >>>
>
>

That's because Python is not a strictly typed language. With proper type propagation compiler helps you writing code the way in meant to be. E.g. the following:

(a, b, c, d) = ('tuple', 'of', 'three')

could be statically disabled, but there is nothing wrong with allowing it either: d would be just a no-op, you will know it for sure the moment you try using it.

On 10/6/2010 11:58 PM, Walter Bright wrote:
> Russel Winder wrote:
>> Python may be the best base to compare things to as tuple assignment has been in there for years.
>>
>> Pythons choice is not a car/cdr approach but an exact match approach. so if t represents a tuple datum or a function returning a tuple:
>>
>>         x = t
>>
>> then x is a tuple -- remembering that variables are all just references to objects implemented via keys in a dictionary, and:
>>
>>         a , b , c = t
>> or
>>         ( a , b , c ) = t
>>
>> is tuple assignment where now t is required to be a tuple of length 3. cf.
> 
> The first thought was to make it an exact match approach. Andrei thought that the car/cdr one was better, though, and I find it intuitively appealing, too. Perhaps Python missed an important use case?
> 
> Or perhaps the ambiguity as to whether the last item gets to be a value or another tuple is too much.

I think the ambiguity should be avoided.  There was one language I used ages ago that used a token to signal the use of the last arg as a 'rest' usage.  If I remember right, it used:

  (a, @b) = aggregate; // a = aggregate[0], b = aggregate[1..$]

It also allowed: (a, @aggregate) = aggregate; // essentially a pop operation.

That said, it was a weakly typed language, so it's application to D has to be taken with an appropriate dose of salt.  For D, I think using the @ would clash badly with the attribute syntax, so an alternative that's not horrid:

   (a, b...) = aggregate;

Later,
Brad

On Thu, 07 Oct 2010 11:42:06 +0400, Brad Roberts <braddr@puremagic.com> wrote:

> On 10/6/2010 11:58 PM, Walter Bright wrote:
>> Russel Winder wrote:
>>> Python may be the best base to compare things to as tuple assignment has
>>> been in there for years.
>>>
>>> Pythons choice is not a car/cdr approach but an exact match approach.
>>> so if t represents a tuple datum or a function returning a tuple:
>>>
>>>         x = t
>>>
>>> then x is a tuple -- remembering that variables are all just references
>>> to objects implemented via keys in a dictionary, and:
>>>
>>>         a , b , c = t
>>> or
>>>         ( a , b , c ) = t
>>>
>>> is tuple assignment where now t is required to be a tuple of length 3.
>>> cf.
>>
>> The first thought was to make it an exact match approach. Andrei thought that
>> the car/cdr one was better, though, and I find it intuitively appealing, too.
>> Perhaps Python missed an important use case?
>>
>> Or perhaps the ambiguity as to whether the last item gets to be a value or
>> another tuple is too much.
>
> I think the ambiguity should be avoided.  There was one language I used ages ago
> that used a token to signal the use of the last arg as a 'rest' usage.  If I
> remember right, it used:
>
>   (a, @b) = aggregate; // a = aggregate[0], b = aggregate[1..$]
>
> It also allowed: (a, @aggregate) = aggregate; // essentially a pop operation.
>
> That said, it was a weakly typed language, so it's application to D has to be
> taken with an appropriate dose of salt.  For D, I think using the @ would clash
> badly with the attribute syntax, so an alternative that's not horrid:
>
>    (a, b...) = aggregate;
>
> Later,
> Brad

Interesting idea, I like it!

On 10/7/10 1:43 CDT, Russel Winder wrote:
> On Wed, 2010-10-06 at 23:08 -0700, Walter Bright wrote:
>> If expr represents a tuple, we (Andrei and I) were thinking about the syntax:
>>
>>       auto (a, b, c, d) = expr;
>>
>> being equivalent to:
>>
>>       auto t = expr; auto a = t[0]; auto b = t[1]; auto c = t[2 .. $];
>>
>> You can also do this with arrays, such that:
>>
>>       float[3] xyz;
>>       auto (x, y, z) = xyz;
>>
>> The Lithpers among you will notice that this essentially provides a handy
>> car,cdr shortcut for tuples and arrays:
>>
>>       auto (car, cdr) = expr;
>
>
> Python may be the best base to compare things to as tuple assignment has
> been in there for years.
>
> Pythons choice is not a car/cdr approach but an exact match approach.

So then we'd have the proposed notation not work with dynamic arrays - only with static arrays and tuples.

Andrei

On 10/07/2010 09:03 AM, Walter Bright wrote:
> Russel Winder wrote:
>> Python may be the best base to compare things to as tuple assignment has
>> been in there for years.
>
> Too segue this into the previous thread, how does Python treat (1)? Is
> it a floor wax or a dessert topping?
>
> http://www.nbc.com/saturday-night-live/video/shimmer-floor-wax/1056743/

(1) == 1
(1,) == tuple([1])

On 10/07/2010 08:08 AM, Walter Bright wrote:
> If expr represents a tuple, we (Andrei and I) were thinking about the
> syntax:
>
> auto (a, b, c, d) = expr;
>
> being equivalent to:
>
> auto t = expr; auto a = t[0]; auto b = t[1]; auto c = t[2 .. $];
>
> You can also do this with arrays, such that:
>
> float[3] xyz;
> auto (x, y, z) = xyz;
>
> The Lithpers among you will notice that this essentially provides a
> handy car,cdr shortcut for tuples and arrays:
>
> auto (car, cdr) = expr;

Python 3 uses:
car, *cdr = expr
a, *b, c = [1,2,3,4,5] # leaves a=1, b=[2,3,4], c=5

I would like D to have
(car, cdr...) = expr
(a, b..., c) = [1,2,3,4,5]

for the equivalent.

Our varargs syntax is b..., theirs is *b. So it mirrors a bit, there. :-)