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.

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])