View mode: basic / threaded / horizontal-split · Log in · Help
October 07, 2010
Tuple assignment
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;
October 07, 2010
Re: Tuple assignment
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
October 07, 2010
Re: Tuple assignment
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.
October 07, 2010
Re: Tuple assignment
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/
October 07, 2010
Re: Tuple assignment
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.
October 07, 2010
Re: Tuple assignment
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
October 07, 2010
Re: Tuple assignment
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!
October 07, 2010
Re: Tuple assignment
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
October 07, 2010
Re: Tuple assignment
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])
October 07, 2010
Re: Tuple assignment
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. :-)
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home