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;
Tuple assignment
Python has tuple assignment so you see things like: previous, current = current, previous + current especially if you are doing silly things like calculating Fibonacci Sequence values. Translating this to D, you end up with: TypeTuple!(current, next) = tuple(next , current +next); I am assuming this is horrendously inefficient at run time compared to having the intermediate value explicit: auto t = next; next = current + next; current = t; or is it? -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
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 "", line 1, in ValueError: too many values to unpack >>> a , b , c , d = t Traceback (most recent call last): File "", line 1, in ValueError: need more than 3 values to unpack >>> -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
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.
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/
Re: Tuple assignment
On Thu, 07 Oct 2010 10:43:18 +0400, 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 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 "", line 1, in
ValueError: too many values to unpack
>>> a , b , c , d = t
Traceback (most recent call last):
File "", line 1, in
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.
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
Re: Tuple assignment
On Thu, 07 Oct 2010 11:42:06 +0400, Brad Roberts 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!
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
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])
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. :-)
Re: Tuple assignment
Denis Koroskin Wrote:
> 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.
Python has the special symbol "_" which is used exactly as a no-op (you could
call it "foo" it you wanted, but "_"
doesn't create new memory assignments) so you can expand arbitrary tuples
without creating new symbols:
a, b, c, _ = ('tuple', 'of', 'three')
I like the proposal for D, but I fear it could be a source of bugs (you expect
the tuple to expand to 4 values
but silently is expanding to only 3, leaving the fourth unchangued).
Re: Tuple assignment
On 10/7/10 3:55 CDT, Pelle wrote: 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. :-) Excellent idea! Andrei
Re: Tuple assignment
Andrei Alexandrescu, el 7 de octubre a las 03:20 me escribiste:
> 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 .. $];
I guess d being missing is a typo, right?
> >>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.
Unless you add a dynamic "bound" check as when accessing a dynamic array
item, something like:
auto t = expr; assert (t.lenght == 4); auto a = t[0]; auto b = t[1];
auto c = t[2]; auto d = t[3];
I like the idea of having exact match approach and the explicit syntax
for getting the rest as Brad said. But in all the years I used Python,
I never needed that syntax, maybe because most of the times when I use
the tuple expansion I know the size or I want to truncate, or I use
something to generate the data, like split(), that takes an extra
parameter to do that:
l = [1, 2, 3]
a, b, c = l # known lenght
a, b = l[:2] # truncation (like l[0..2] in D)
a, b = '1,2,3'.split(',', 1) # get the rest in b (but it will be a string)
car, cdr = l[0], l[1:] # just a little more verbose
--
Leandro Lucarella (AKA luca) http://llucax.com.ar/
--
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
--
careful to all animals (never washing spiders down the plughole),
keep in contact with old friends (enjoy a drink now and then),
will frequently check credit at (moral) bank (hole in the wall),
Re: Tuple assignment
Walter Bright napisał: > 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 .. $]; Typo? If not, what is 'd'? Either way, I'd like mismatching tuple lengths to fail, not assign the tail to the last variable. Or, as pelle brought up: auto (a, b..., c) = expr, where b = expr[1..2] and you may have only one ... in the lhs. It's not bad. > 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; Nice. It's all nice but as my colleague once said: put it on the todo list right after 'learn Portugese'. -- Tomek
Re: Tuple assignment
Juanjo Alvarez:
> Python has the special symbol "_" which is used exactly as
> a no-op (you could call it "foo" it you wanted, but "_"
> doesn't create new memory assignments) so you can expand
> arbitrary tuples without creating new symbols:
>
> a, b, c, _ = ('tuple', 'of', 'three')
This is false both in Python2 and Python3.
In Python3 there is the syntax:
a, *bc = ('tuple', 'of', 'three')
That's semantically similar to the proposed D syntax:
auto record(a, bc...) = record('tuple', 'of', 'three')
Bye,
bearophile
Re: Tuple assignment
On Thu, 07 Oct 2010 15:14:12 -0400, bearophile
wrote:
This is false both in Python2 and Python3.
What is exactly false on what I said?
a, *bc = ('tuple', 'of', 'three')
Yes, that's the syntax for assignment of the remainder, I was
speaking about *ignoring* the remainder without having it assigned to
the last element which was one of the proposed effects in the message
before mine's.
Re: Tuple assignment
Juanjo Alvarez wrote:
> On Thu, 07 Oct 2010 15:14:12 -0400, bearophile
> wrote:
>> This is false both in Python2 and Python3.
>
>
> What is exactly false on what I said?
> python
Python 2.6.5 (r265:79063, Apr 1 2010, 05:28:39)
[GCC 4.4.3 20100316 (prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> a, b, c, _ = ('tuple', 'of', 'three')
Traceback (most recent call last):
File "", line 1, in
ValueError: need more than 3 values to unpack
>>>
Jerome
--
mailto:jeber...@free.fr
http://jeberger.free.fr
Jabber: jeber...@jabber.fr
signature.asc
Description: OpenPGP digital signature
Re: Tuple assignment
On Fri, 08 Oct 2010 16:11:53 -0400, bearophile
wrote:
This syntax you have explained doesn't do what you think it does:
a, b, c, _ = ('tuple', 'of', 'three')
That was a typo, I meant to write:
a, b, _ = ('tuple', 'of', 'three')
Re: Tuple assignment
Juanjo Alvarez, el 9 de octubre a las 04:02 me escribiste:
> On Fri, 08 Oct 2010 16:11:53 -0400, bearophile
> wrote:
> >This syntax you have explained doesn't do what you think it does:
> >a, b, c, _ = ('tuple', 'of', 'three')
>
> That was a typo, I meant to write:
>
> a, b, _ = ('tuple', 'of', 'three')
Even then, the _ identifier is not special all :)
--
Leandro Lucarella (AKA luca) http://llucax.com.ar/
--
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
--
Me encanta el éxito; por eso prefiero el estado de progreso constante,
con la meta al frente y no atrás.
-- Ricardo Vaporeso. Punta del Este, Enero de 1918.
Re: Tuple assignment
On 5/9/2015 10:16 AM, Russel Winder via Digitalmars-d wrote: Python has tuple assignment so you see things like: previous, current = current, previous + current especially if you are doing silly things like calculating Fibonacci Sequence values. Translating this to D, you end up with: TypeTuple!(current, next) = tuple(next , current +next); I am assuming this is horrendously inefficient at run time compared to having the intermediate value explicit: auto t = next; next = current + next; current = t; or is it? It probably depends on the compiler. The way to find out is to look at the generated assembler. Tuples are implemented as structs. I know that ldc is capable of slicing structs into register-sized pieces and optimizing them independently, dmd does not. So ldc would very possibly generate the kind of code for that that you'd like.
Re: Tuple assignment
On Sat, 2015-05-09 at 13:07 -0700, Walter Bright via Digitalmars-d wrote: > […] > It probably depends on the compiler. The way to find out is to look > at the > generated assembler. assembly language file, not assembler (which is the program to do the transformation) ldc2 and gdc have options to write the assembly language file, maybe I am missing it but dmd appears not to advertise such an option. > Tuples are implemented as structs. I know that ldc is capable of > slicing structs > into register-sized pieces and optimizing them independently, dmd > does not. So > ldc would very possibly generate the kind of code for that that > you'd like. I shall investigate with gdc as well as ldc. Though, sadly, whilst gdc is in Debian it is not in Fedora. :-( -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Tuple assignment
On Saturday, 9 May 2015 at 17:16:58 UTC, Russel Winder wrote: Python has tuple assignment so you see things like: previous, current = current, previous + current especially if you are doing silly things like calculating Fibonacci Sequence values. Translating this to D, you end up with: TypeTuple!(current, next) = tuple(next , current +next); This works right now and is quite aesthetically pleasing: tuple(current, next) = tuple(next , current +next); Note, however, that this is not a tuple assignment. It is assignment of a misleadingly-named anonymous struct type that is implemented in the standard library. This is an actual tuple assignment as supported by the compiler: a.tupleof = b.tupleof; I think it should work for any two structs as long their fields are public and individually assignment-compatible. I believe it is as efficient as individual assignments on all D implementations. A lot of people seem to want better sugar for tuple or tuple-like things in D and do not consider std.typecons sufficient (or at least find the names it uses confusing). Such a feature would work very nicely with D's auto types, return and lambda argument type inference, etc. See LINQ.
Re: Tuple assignment
On Saturday, 9 May 2015 at 20:07:00 UTC, Walter Bright wrote: It probably depends on the compiler. The way to find out is to look at the generated assembler. fwiw, I tried to look at this earlier and found out a single tuple generates too much assembly for asm.dlang.org to display ;)
Re: Tuple assignment
On Sat, 2015-05-09 at 13:07 -0700, Walter Bright via Digitalmars-d wrote: > On 5/9/2015 10:16 AM, Russel Winder via Digitalmars-d wrote: > > Python has tuple assignment so you see things like: > > > > previous, current = current, previous + current > > > > especially if you are doing silly things like calculating Fibonacci > > Sequence values. Translating this to D, you end up with: > > > > TypeTuple!(current, next) = tuple(next , current +next); > > > > I am assuming this is horrendously inefficient at run time > > compared to > > having the intermediate value explicit: > > > > auto t = next; > > next = current + next; > > current = t; > > > > or is it? > > It probably depends on the compiler. The way to find out is to look > at the > generated assembler. Using LDC, the tuple version generates more code unoptimized, but with optimization, the exact same assembly language code is generated for the two cases. Win. Albeit the D syntax is not as nice as the Python syntax. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Tuple assignment
On Sun, 2015-05-10 at 08:14 +, Oren Tirosh via Digitalmars-d wrote: > On Saturday, 9 May 2015 at 17:16:58 UTC, Russel Winder wrote: > > […] > > TypeTuple!(current, next) = tuple(next , current +next); This works. > This works right now and is quite aesthetically pleasing: > > tuple(current, next) = tuple(next , current +next); This does not. At least the tests fail with this where they do not with the previous. > […] -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Tuple assignment
On Sunday, 10 May 2015 at 08:28:24 UTC, Russel Winder wrote: On Sun, 2015-05-10 at 08:14 +, Oren Tirosh via Digitalmars-d wrote: On Saturday, 9 May 2015 at 17:16:58 UTC, Russel Winder wrote: > […] > TypeTuple!(current, next) = tuple(next , current > +next); This works. I did not mean imply that it doesn't, just that what I wrote is not some proposed syntax for tuple assignment but something that actually works now. This works right now and is quite aesthetically pleasing: tuple(current, next) = tuple(next , current +next); This does not. At least the tests fail with this where they do not with the previous. Works for me. If this is version or compiler dependent this definitely needs investigation.
Re: Tuple assignment
On Sun, 2015-05-10 at 08:47 +, Oren Tirosh via Digitalmars-d wrote: > […] > > > tuple(current, next) = tuple(next , current +next); > > […] > Works for me. If this is version or compiler dependent this > definitely needs investigation. It does not for me using rdmd 2.067. My implementation of nth Fibonacci Number leads to success for my version but not for yours. Maybe we should exchange codes offlist? -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Tuple assignment
On 5/10/2015 1:07 AM, Russel Winder via Digitalmars-d wrote: ldc2 and gdc have options to write the assembly language file, maybe I am missing it but dmd appears not to advertise such an option. http://www.digitalmars.com/ctg/obj2asm.html
Re: Tuple assignment
On Sunday, 10 May 2015 at 08:07:38 UTC, Russel Winder wrote: On Sat, 2015-05-09 at 13:07 -0700, Walter Bright via Digitalmars-d wrote: […] It probably depends on the compiler. The way to find out is to look at the generated assembler. assembly language file, not assembler (which is the program to do the transformation) ldc2 and gdc have options to write the assembly language file, maybe I am missing it but dmd appears not to advertise such an option. What's wrong with objdump?
Re: Tuple assignment
On 10 May 2015 at 21:41, John Colvin via Digitalmars-d wrote: > On Sunday, 10 May 2015 at 08:07:38 UTC, Russel Winder wrote: >> >> On Sat, 2015-05-09 at 13:07 -0700, Walter Bright via Digitalmars-d wrote: >>> >>> […] >>> It probably depends on the compiler. The way to find out is to look at >>> the generated assembler. >> >> >> assembly language file, not assembler (which is the >> program to do the transformation) >> >> ldc2 and gdc have options to write the assembly language file, maybe I >> am missing it but dmd appears not to advertise such an option. > > > What's wrong with objdump? Assembly has more information, such as .align and .loc directives. ;-)
Re: Tuple assignment
On 5/10/2015 1:18 AM, Russel Winder via Digitalmars-d wrote: Using LDC, the tuple version generates more code unoptimized, but with optimization, the exact same assembly language code is generated for the two cases. Win. This is what makes D's ranges+algorithms so attractive. They are easier to write correct code in, and when optimized produce the same code.
Re: Tuple assignment
On 2015-05-10 10:14, Oren Tirosh wrote: I think it should work for any two structs as long their fields are public and individually assignment-compatible. Just for the record, "tupleof" bypasses protection. -- /Jacob Carlborg
Re: Tuple literal syntax + Tuple assignment
On 07/10/2010 19:45, Andrei Alexandrescu wrote: On 10/7/10 12:45 CDT, Michel Fortin wrote: On 2010-10-07 12:34:33 -0400, Andrei Alexandrescu said: My suggestion is that we deprecate TypeTuple and we call it AliasTuple because that's really what it is - it's a tuple of stuff that can be passed in as an alias parameter. Personally, I like D built-in tuples; they're so simple. At the core they're just a group of "things". They are terrible, awful, despiteful. They don't compose with anything; you can't have an array of tuples or a hash of tuples. They can't be returned a from a function. They spread their legs in function parameter lists without any control (flattening is bad, right?) Built-in tuples are the pitts. The one thing they're good for is as a back-end for std.typecons.Tuple. In fairness, my impression is they were not meant to compose with anything or be returned with a function. They were created not as a first class type, but as a metaprogramming construct, whose purpose was *exactly* for capturing parameters for templates or functions and expanding them automatically. They were a great boon for D's metaprogramming capabilities. As such they were not meant to emulate tuples as in Python's tuples, or any record type in general. But because they could partially be used as such, and because they share the same name, a lot of comparisons are made, which results in this idea that D's tuples are inferior. This is not saying it would not be useful to have functionality like Python's tuples. -- Bruno Medeiros - Software Engineer
Re: Tuple literal syntax + Tuple assignment
In the two threads (that are a single thread) most of the things I've seen are bad/wrong. I have discussed about Tuples several times in the D newsgroup and in Bugzilla. Please don't ignore all my work. Before designing tuple syntax you must decide what the purpose of D tuples is. Then you have to solve the design problems, and avoid all (or most) corner cases. In this discussion it's useful to have a certain experience of languages that use tuples often, as Python and others. Tuples have some purposes: - Python, Go and other languages show that it's handy to allow functions to return multiple values, this means a tuple. - A handy tuple unpacking is useful at the calling point of a function that returns multiple return values. - Tuples are also useful as quick-and-dirty structs, to sort items in a different order, etc. It's useful to use [] to access tuple items, to slice tuples, concat them. It's useful for tuples to have a good textual representation, to be comparable lexicographically and to be hashable. Another design decision is if tuples have a nominative or structural type, this problem comes out in this bug report: http://d.puremagic.com/issues/show_bug.cgi?id=4128 In my opinion it's good for a built-in D tuple to be a structural type. This also means you are allowed to perform an == among two tuples of different length (the result is known statically to be always false). I assume that D tuples know their length at compile-time. Another significant problem is about naming things, currently the situation is a mess: http://www.digitalmars.com/d/archives/digitalmars/D/Tuple_TypeTuple_tupleof_etc_113005.html http://d.puremagic.com/issues/show_bug.cgi?id=4113 In the end I have suggested to name "record" the typecons tuples, and "tuple" the typetuples. I have several bug reports and enhancement requests about tuples, please take them into account: http://d.puremagic.com/issues/show_bug.cgi?id=4577 http://d.puremagic.com/issues/show_bug.cgi?id=4582 http://d.puremagic.com/issues/show_bug.cgi?id=4591 http://d.puremagic.com/issues/show_bug.cgi?id=4666 http://d.puremagic.com/issues/show_bug.cgi?id=4846 Walter: > A lot of it foundered on what the syntax for tuple literals should be. The top > of the list is simply enclosing them in ( ). This is a bad idea. It has caused troubles in Python because of the singleton syntax (tuple with 1 item). One solution is to use a special unambigous delimiter to denote tuples, like (a similar solution is used in the Fortress language): (||) (|1|) (|1, 2|) (|1, 2, 3|) (|1, 2, 3, 4|) Otherwise a good solution is to use a name: record() record(1) record(1, 2) record(1, 2, 3) record(1, 2, 3, 4) I prefer the record() solution, but the first solution too acceptable. > Finally, I got to thinking, why not just make it a special case: > > ( ) == tuple > (a) == parenthesized expression This is not acceptable. No special cases, please. D has already a ton of special cases. Python solves this with the (1,) syntax, but it's not nice, it's error-prone, and it confuses newbies. > If expr represents a tuple, we (Andrei and I) were thinking about the syntax: > > auto (a, b, c, d) = expr; On this topic I have this enhancement request: http://d.puremagic.com/issues/show_bug.cgi?id=4579 > The Lithpers among you will notice that this essentially provides a handy > car,cdr shortcut for tuples and arrays: > > auto (car, cdr) = expr; This is bad, it's not explicit enough. If you want to support this semantics then the syntax has to show what you mean. Python uses a * to denote "grab the whole tail". In D you may use something else, others have suggested tree points, this works with dynamic arrays too: auto (car, cdr...) = expr; Regarding field names for tuples, I have used Python and I like the optional names of D tuples (records). In some situations you don't need names, but in other situations field names are handy and help avoid bugs. In Python code that processes and uses tuples contains too many [0] [1] [2] etc that aren't readable and are bug-prone. But a good management of such names asks for the names to not change the type of the tuple, this is why I talk about structural typing for records. Bye, bearophile
Re: Tuple literal syntax + Tuple assignment
bearophile wrote: In my opinion it's good for a built-in D tuple to be a structural type. This also means you are allowed to perform an == among two tuples of different length (the result is known statically to be always false). I understand (and agree to) the opinion that tuples should be structural types, but why allow comparison of tuples of different lengths? Walter: A lot of it foundered on what the syntax for tuple literals should be. The top of the list is simply enclosing them in ( ). This is a bad idea. It has caused troubles in Python because of the singleton syntax (tuple with 1 item). One solution is to use a special unambigous delimiter to denote tuples, like (a similar solution is used in the Fortress language): (|1, 2, 3, 4|) Otherwise a good solution is to use a name: record(1, 2, 3, 4) I prefer the record() solution, but the first solution too acceptable. Yeah, ( T... ) is not a good general tuple syntax. I believe auto( ) is a free syntax in D, and thus could be used for tuples. Thinking more about it, I am no longer as sure. auto (car, cdr...) = expr; I really like this. Regarding field names for tuples, I have used Python and I like the optional names of D tuples (records). In some situations you don't need names, but in other situations field names are handy and help avoid bugs. In Python code that processes and uses tuples contains too many [0] [1] [2] etc that aren't readable and are bug-prone. But a good management of such names asks for the names to not change the type of the tuple, this is why I talk about structural typing for records. I wrote a Tuple implementation for D that supports structural typing: http://pastebin.com/qeYKa5GZ (see line 58-60 for proof) This is a simple proof-of-concept, so don't expect anything impressive from it. -- Simen
Re: Tuple literal syntax + Tuple assignment
On 10/7/10 7:09 CDT, bearophile wrote: In the two threads (that are a single thread) most of the things I've seen are bad/wrong. I have discussed about Tuples several times in the D newsgroup and in Bugzilla. Please don't ignore all my work. Before designing tuple syntax you must decide what the purpose of D tuples is. Then you have to solve the design problems, and avoid all (or most) corner cases. In this discussion it's useful to have a certain experience of languages that use tuples often, as Python and others. Good point. Tuples have some purposes: - Python, Go and other languages show that it's handy to allow functions to return multiple values, this means a tuple. - A handy tuple unpacking is useful at the calling point of a function that returns multiple return values. - Tuples are also useful as quick-and-dirty structs, to sort items in a different order, etc. It's useful to use [] to access tuple items, to slice tuples, concat them. It's useful for tuples to have a good textual representation, to be comparable lexicographically and to be hashable. Yes, excellent. Now I realize we don't have hash for tuples just yet. Another design decision is if tuples have a nominative or structural type, this problem comes out in this bug report: http://d.puremagic.com/issues/show_bug.cgi?id=4128 In my opinion it's good for a built-in D tuple to be a structural type. This also means you are allowed to perform an == among two tuples of different length (the result is known statically to be always false). I assume that D tuples know their length at compile-time. Yah, I think tuples are the quintessential structural types. I think, however, that "==" shouldn't test for prefix (that would be _sub_typing). This is because slicing takes care of it. For example: Tuple!(int, int, int) point3d; Tuple!(int, int) point2d; point2d == point3d; // doesn't compile point2d == point3d[0 .. point2d.length]; // compiles Another significant problem is about naming things, currently the situation is a mess: http://www.digitalmars.com/d/archives/digitalmars/D/Tuple_TypeTuple_tupleof_etc_113005.html http://d.puremagic.com/issues/show_bug.cgi?id=4113 In the end I have suggested to name "record" the typecons tuples, and "tuple" the typetuples. I think we're in good shape with Tuple and tuple. The "other" tuples deserve an odder name. I have several bug reports and enhancement requests about tuples, please take them into account: http://d.puremagic.com/issues/show_bug.cgi?id=4577 http://d.puremagic.com/issues/show_bug.cgi?id=4582 http://d.puremagic.com/issues/show_bug.cgi?id=4591 http://d.puremagic.com/issues/show_bug.cgi?id=4666 http://d.puremagic.com/issues/show_bug.cgi?id=4846 Nice. I like at least some of each. Walter: A lot of it foundered on what the syntax for tuple literals should be. The top of the list is simply enclosing them in ( ). This is a bad idea. It has caused troubles in Python because of the singleton syntax (tuple with 1 item). During our conversation I conveyed my suspicion that that one corner case (which is very often encountered in generic code) will inevitably do this whole thing in, but he was quick to gloss over the issues. I'd be glad to have experience with Python save us some sweat. Do you have any links to discussions regarding the matter? One solution is to use a special unambigous delimiter to denote tuples, like (a similar solution is used in the Fortress language): (||) (|1|) (|1, 2|) (|1, 2, 3|) (|1, 2, 3, 4|) Yup, the banana notation. Otherwise a good solution is to use a name: record() record(1) record(1, 2) record(1, 2, 3) record(1, 2, 3, 4) I prefer the record() solution, but the first solution too acceptable. How about the shorter "tuple"? Wait, it's already there :o). Finally, I got to thinking, why not just make it a special case: ( ) == tuple (a) == parenthesized expression This is not acceptable. No special cases, please. D has already a ton of special cases. Python solves this with the (1,) syntax, but it's not nice, it's error-prone, and it confuses newbies. Evidence please? If expr represents a tuple, we (Andrei and I) were thinking about the syntax: auto (a, b, c, d) = expr; On this topic I have this enhancement request: http://d.puremagic.com/issues/show_bug.cgi?id=4579 The Lithpers among you will notice that this essentially provides a handy car,cdr shortcut for tuples and arrays: auto (car, cdr) = expr; This is bad, it's not explicit enough. If you want to support this semantics then the syntax has to show what you mean. Python uses a * to denote "grab the whole tail". In D you may use something else, others have suggested tree points, this works with dynamic arrays too: auto (car, cdr...) = expr; Nice. Regarding field names for tuples, I have used Python and I like the optional names of D tuples (records). In some situations you don't need names, but in other situ
Re: Tuple literal syntax + Tuple assignment
2010/10/7 bearophile : > Another design decision is if tuples have a nominative or structural type, > this problem comes out in this bug report: > http://d.puremagic.com/issues/show_bug.cgi?id=4128 > Another significant problem is about naming things, currently the situation > is a mess: > http://www.digitalmars.com/d/archives/digitalmars/D/Tuple_TypeTuple_tupleof_etc_113005.html > http://d.puremagic.com/issues/show_bug.cgi?id=4113 > In the end I have suggested to name "record" the typecons tuples, and "tuple" > the typetuples. On these issues, I'm almost agreed with bearophile I think we may not use 'Tuple' as 'a structure packed values'. It is more better that 'Tuple' should *only* use as mixing sequence types and values. My proposals are: 1. We should name definitions of structures. - "Structure that all of fields have name" shuld be called 'Struct'. - "Structure that some of fields have name" shuld be called 'Odd struct'. - "Structure that none of fields have name" shuld be called 'Record'. Struct∈Odd struct∈Record 2. We remove field namming funcion from std.typecons.tuple, and rename it to Record. 3. We rename std.typetuple.TypeTuple to Tuple. pseudo codes: auto a = Record!(int, int)(10, 20); auto b = Struct!(int, "x", int, "y")(100, 200); //a = b; //should not compile, named field(x, y) cannot assign to unnamed field b = a; //should compile, unnamed field can assign to named field assert(b[0] == 10); assert(b[1] == 20); auto c = OddStruct!(int, "x", int)(15, 25); //a = c; //shuld not compile, named field(x) cannot assign to unnamed field b = c; //shuld compile assert(b[0] == 15); assert(b[1] == 25); c = a; //shuld compile assert(c[0] == 10); assert(c[1] == 20); thanks. Kenji Hara.
Re: Tuple literal syntax + Tuple assignment
On 10/7/10 11:11 CDT, kenji hara wrote:
> 2010/10/7 bearophile:
>> Another design decision is if tuples have a nominative or structural type,
>> this problem comes out in this bug report:
>> http://d.puremagic.com/issues/show_bug.cgi?id=4128
>
>> Another significant problem is about naming things, currently the situation
>> is a mess:
>> http://www.digitalmars.com/d/archives/digitalmars/D/Tuple_TypeTuple_tupleof_etc_113005.html
>> http://d.puremagic.com/issues/show_bug.cgi?id=4113
>> In the end I have suggested to name "record" the typecons tuples, and
>> "tuple" the typetuples.
>
> On these issues, I'm almost agreed with bearophile
>
> I think we may not use 'Tuple' as 'a structure packed values'.
> It is more better that 'Tuple' should *only* use as mixing sequence
> types and values.
The problem with this is that it departs from nomenclature that is
agreed by everyone else, which is provincial.
First off, a tuple IS agreed to be an ordered collection of
heterogeneous items. Google reveals copious evidence, both in math and
programming language theory.
Benjamin Pierce's "Types and programming languages", a book that all PL
students sleep with under their pillow, defines tuples in section 11.7
(entitled "Tuples") like D does. The first paragraph:
"It is easy to generalize the binary products of the previous section to
n-ary products, often called tuples. For example, {1,2,true} is a
3-tuple containing two numbers and a Boolean. Its type is written
{Nat,Nat,Bool}."
The following section defines records as tuples with labeled fields. I
don't think it's a crime that D calls both tuples. We could define
Record just to be more Catholic than the Pope, but I don't see a
necessity there. At any rate, "Tuple" is correct, known, understood, and
accepted.
D's built in type tuples (those used with TypeTuple) are weird. They are
an artifact of the language that has no meaning outside it. Such tuples
are defined as "anything that could be a template parameter", which
really ties them to various language design decisions. My suggestion is
that we deprecate TypeTuple and we call it AliasTuple because that's
really what it is - it's a tuple of stuff that can be passed in as an
alias parameter.
> My proposals are:
> 1. We should name definitions of structures.
> - "Structure that all of fields have name" shuld be called 'Struct'.
> - "Structure that some of fields have name" shuld be called 'Odd struct'.
> - "Structure that none of fields have name" shuld be called 'Record'.
>
> Struct∈Odd struct∈Record
>
> 2. We remove field namming funcion from std.typecons.tuple, and rename
> it to Record.
>
> 3. We rename std.typetuple.TypeTuple to Tuple.
>
>
> pseudo codes:
>
> auto a = Record!(int, int)(10, 20);
This is not a record by Pierce.
> auto b = Struct!(int, "x", int, "y")(100, 200);
This is a record by Pierce.
> auto c = OddStruct!(int, "x", int)(15, 25);
We could reject this during compilation if needed.
I don't see anything confusing grouping the above under "Tuple".
Andrei
Re: Tuple literal syntax + Tuple assignment
2010年10月8日1:34 Andrei Alexandrescu :
> On 10/7/10 11:11 CDT, kenji hara wrote:
>> 2010/10/7 bearophile:
>>> Another design decision is if tuples have a nominative or structural type,
>>> this problem comes out in this bug report:
>>> http://d.puremagic.com/issues/show_bug.cgi?id=4128
>>
>>> Another significant problem is about naming things, currently the situation
>>> is a mess:
>>> http://www.digitalmars.com/d/archives/digitalmars/D/Tuple_TypeTuple_tupleof_etc_113005.html
>>> http://d.puremagic.com/issues/show_bug.cgi?id=4113
>>> In the end I have suggested to name "record" the typecons tuples, and
>>> "tuple" the typetuples.
>>
>> On these issues, I'm almost agreed with bearophile
>>
>> I think we may not use 'Tuple' as 'a structure packed values'.
>> It is more better that 'Tuple' should *only* use as mixing sequence
>> types and values.
>
> The problem with this is that it departs from nomenclature that is
> agreed by everyone else, which is provincial.
>
> First off, a tuple IS agreed to be an ordered collection of
> heterogeneous items. Google reveals copious evidence, both in math and
> programming language theory.
>
> Benjamin Pierce's "Types and programming languages", a book that all PL
> students sleep with under their pillow, defines tuples in section 11.7
> (entitled "Tuples") like D does. The first paragraph:
>
> "It is easy to generalize the binary products of the previous section to
> n-ary products, often called tuples. For example, {1,2,true} is a
> 3-tuple containing two numbers and a Boolean. Its type is written
> {Nat,Nat,Bool}."
>
> The following section defines records as tuples with labeled fields. I
> don't think it's a crime that D calls both tuples. We could define
> Record just to be more Catholic than the Pope, but I don't see a
> necessity there. At any rate, "Tuple" is correct, known, understood, and
> accepted.
I understood that 'Tuple' is a generic word in math/language theory.
Withdraw my proposals.
> D's built in type tuples (those used with TypeTuple) are weird. They are
> an artifact of the language that has no meaning outside it. Such tuples
> are defined as "anything that could be a template parameter", which
> really ties them to various language design decisions. My suggestion is
> that we deprecate TypeTuple and we call it AliasTuple because that's
> really what it is - it's a tuple of stuff that can be passed in as an
> alias parameter.
It sounds for me that AliasTuple is a limited tuple contains only
alias parameters(exclude types).
I associate three kinds of template parameter (Type, Value, Alias)
with names '{Type|Value|Alias}Tuple'.
So I hope it will be called 'Tuple' in library, too.
(Given these, can I call std.typecons.Tuple ValueTyple?)
Thanks for your answer.
Kenji Hara
Re: Tuple literal syntax + Tuple assignment
On 2010-10-07 12:34:33 -0400, Andrei Alexandrescu said: My suggestion is that we deprecate TypeTuple and we call it AliasTuple because that's really what it is - it's a tuple of stuff that can be passed in as an alias parameter. Personally, I like D built-in tuples; they're so simple. At the core they're just a group of "things". If you put only types in the tuple then it becomes usable as a type, and if you put only values in the tuple then it becomes usable as a value, and if I put variable declarations in the tuple then it becomes usable as a single variable aliased to all those variables, and if I mix all kind of things then it's just a heterogenous tuple that's probably only suitable as a template parameter. Why should I know beforehand if I'm defining an alias tuple, a type tuple, a value tuple, or a whatever tuple? Seriously, the tuple is just a group of those "things" I put in it, and the compiler will tell me whenever I try to put that tuple where it doesn't belong. Now, it sure would make sense to have a way to enforce whether a tuple is valid as a type or a valid as a value. But for many uses it isn't necessary, and it does simplify things to not have to care about it. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: Tuple literal syntax + Tuple assignment
Thu, 07 Oct 2010 13:45:16 -0400, Michel Fortin wrote: > On 2010-10-07 12:34:33 -0400, Andrei Alexandrescu > said: > >> My suggestion is that we deprecate TypeTuple and we call it AliasTuple >> because that's really what it is - it's a tuple of stuff that can be >> passed in as an alias parameter. > > Personally, I like D built-in tuples; they're so simple. At the core > they're just a group of "things". If you put only types in the tuple > then it becomes usable as a type, and if you put only values in the > tuple then it becomes usable as a value, and if I put variable > declarations in the tuple then it becomes usable as a single variable > aliased to all those variables, and if I mix all kind of things then > it's just a heterogenous tuple that's probably only suitable as a > template parameter. > > Why should I know beforehand if I'm defining an alias tuple, a type > tuple, a value tuple, or a whatever tuple? Seriously, the tuple is just > a group of those "things" I put in it, and the compiler will tell me > whenever I try to put that tuple where it doesn't belong. > > Now, it sure would make sense to have a way to enforce whether a tuple > is valid as a type or a valid as a value. But for many uses it isn't > necessary, and it does simplify things to not have to care about it. We were discussing the semantics of the language. You can't design languages & compilers by just saying "do it the simple way, it should just work". The tuples & proposals are already combining several different features: tuples, records, arrays (slices & indexing), varargs, type definitions (type tuples), dependent types, pattern matching, nominative & structural typing, and ad-hoc features (.tupleof which.. in fact isn't any of the three listed tuples). On top of that there are syntactical conflicts. How is that in any possible way simple?
Re: Tuple literal syntax + Tuple assignment
On 10/7/10 12:45 CDT, Michel Fortin wrote: On 2010-10-07 12:34:33 -0400, Andrei Alexandrescu said: My suggestion is that we deprecate TypeTuple and we call it AliasTuple because that's really what it is - it's a tuple of stuff that can be passed in as an alias parameter. Personally, I like D built-in tuples; they're so simple. At the core they're just a group of "things". They are terrible, awful, despiteful. They don't compose with anything; you can't have an array of tuples or a hash of tuples. They can't be returned a from a function. They spread their legs in function parameter lists without any control (flattening is bad, right?) Built-in tuples are the pitts. The one thing they're good for is as a back-end for std.typecons.Tuple. If you put only types in the tuple then it becomes usable as a type, and if you put only values in the tuple then it becomes usable as a value, and if I put variable declarations in the tuple then it becomes usable as a single variable aliased to all those variables, and if I mix all kind of things then it's just a heterogenous tuple that's probably only suitable as a template parameter. Only a fraction of that is true. A tuple is not usable as a value. Andrei
Re: Tuple literal syntax + Tuple assignment
kenji hara: > My proposals are: > 1. We should name definitions of structures. > - "Structure that all of fields have name" shuld be called 'Struct'. > - "Structure that some of fields have name" shuld be called 'Odd struct'. > - "Structure that none of fields have name" shuld be called 'Record'. We already have structs, TypeTuples and Tuples, I'd like to reduce them to 2 types, not extend them to 4 :-) Bye, bearophile
Re: Tuple literal syntax + Tuple assignment
Andrei:
Another possible useful feature for tuples is to unpack them in foreach too:
import std.algorithm, std.stdio, std.range;
void main() {
foreach (p; zip([1, 2, 3], "abcd"))
writeln(p[0], " ", p[1]);
writeln();
foreach ((a, b); zip([1, 2, 3], "abcd"))
writeln(a, " ", b);
}
A related handy feature, present in Python2 is destructuring (unpacking) in
function signature:
- upacking syntax, pattern matching
>>> def foo((x, y), z): print y
...
>>> foo("ab", 2)
b
This allows you to do many things, like define a lambda function that swaps
items of the given 2-tuple:
lambda (seq,freq): (freq,seq)
Python3 has removed this automatic unpacking (not because that feature is not
handy, but mostly to simplify the source code of CPython!), and it has added
the unpaking syntax for n items:
first, second, *tail = (1, 2, 3, 4)
Recently I have written something about support for slicing tuples and similar
compile-time sized structures:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=117890
>I think, however, that "==" shouldn't test for prefix<
You are right, that's an error of mine caused by thinking about tuple lengths
as immutable but known at run-time only, as in Python. It's better to disallow
at compile time the opEquals of tuples of different length.
>I think we're in good shape with Tuple and tuple. The "other" tuples deserve
>an odder name.<
I don't love the name "record" and I agree that "tuple" is OK. But if in the
language there is a built-in attribute named "tupleof" that returns something
that's not a tuple, then... it's not nice. This is why I have suggested to name
tuples the built-in ones and record() the library+SyntaxSugar defined ones.
Naming them record is not terrible, in my opinion.
>During our conversation I conveyed my suspicion that that one corner case
>(which is very often encountered in generic code) will inevitably do this
>whole thing in, but he was quick to gloss over the issues. I'd be glad to have
>experience with Python save us some sweat. Do you have any links to
>discussions regarding the matter?<
>Evidence please?<
There are endless questions and discussions in Python newsgroups about the
syntax of Python tuples, you may find several of them in comp.lang.python. Some
of them:
http://groups.google.com/group/comp.lang.python/browse_thread/thread/673344303e27ed6/
http://groups.google.com/group/comp.lang.python/browse_thread/thread/699ec8cb75c7cbda/088aee81cdca92ec?lnk=gst&q=%22tuple+syntax%22#088aee81cdca92ec
Python programmers eventually always learn to manage them correctly, but many
other Python features don't generate that many discussions, this means their
syntax is not as clean and simple as many other Python features.
I've taught Python, and I've seen that I need several minutes to teach how
tuples are in Python. While such problems are not present when I explain the
Python list syntax, that is more clean.
In Python lists are arrays dynamic on the right. You need to put the items
inside square brackets. So if there's nothing between them, you have an empty
list, []. This is simple.
A Python tuple is generally not defined by the ( ) . It is defined by the comma.
So this is a tuple of 3 items:
a = (1, 2, 3)
But () is not necessary, so this too is the same tuple:
a = 1, 2, 3
So (1) is not a 1-tuple, you need a comma:
(1,)
I've seen cases where programmers forget or don't see that comma.
And there's another special case, the empty tuple. This is the only case where
the ( ) are actually part of the tuple syntax, and necessary:
()
There's another way to define an empty tuple, using the type:
tuple()
There are also some corner cases, like this one present in Python2.6 still:
>>> (a,) = (1,)
>>> () = ()
File "", line 1
SyntaxError: can't assign to ()
In the end all this doesn't cause frequent bugs in Python programs, but it's
not clean nor elegant, especially if you see this in the context of a language
as clean as Python.
> Yup, the banana notation.
It's clean, short, unambiguous, and I think it has no corner cases, so it's not
terrible. This is why Fortress uses similar syntax. It may be just sugar for
the Tuple/Record of typecons.
>> auto (car, cdr...) = expr;
> Nice.
Not invented by me :-)
>>Regarding field names for tuples, I have used Python and I like the optional
>>names of D tuples (records). In some situations you don't need names, but in
>>other situations field names are handy and help avoid bugs. In Python code
>>that processes and uses tuples contains too many [0] [1] [2] etc that aren't
>>readable and are bug-prone.<<
>Evidence please?<
I am not sure what kind of evidence you may want. The need to give a name to
tuple fields was so strong that Hettinger has added them as
collections.namedtuple, this was a early Python implementation (later
translated to C):
http://code.activestate.com/recipes/500261-named-tuples/
If you h
