subject:"Tuple assignment"

I recall having seen an example of using some D magic (via mixin 
perhaps?) to realize tuple destructuring in assignments like


magic(first, _, second) = expression.findSplit(separator);

somewhere. But I can't seem to find it right now.

References anyone?

BTW :I'm aware of Kenjis PR, which I am very much longing for ;)

Re: Destructured Tuple Assignment

2015-05-15 Thread Artur Skawina via Digitalmars-d-learn

   import std.algorithm;

   template magicassign(A...) {
  void magicassign(B)(B b) @property {
 foreach(I, ref a; A)
static if (!is(typeof(A[I]):typeof(null)))
   a = b[I];
  }
   }

   template let(string D) {
  mixin({
 enum sdsl = D.findSplit(=);
 mixin(`struct S { int `~sdsl[0]~`; }`);
 string code = `auto v = ` ~ sdsl[2] ~ `;`;
 foreach (I, _; typeof(S.tupleof))
code ~= `auto ` ~ S.tupleof[I].stringof ~ ` = v[`~I.stringof~`]; `;
 return code;
  }());
   }

   void main(string[] args) {
  import std.stdio;

  string a, b;
  magicassign!(a, null, b) = args[1].findSplit(-);
  writeln(a);
  writeln(b);

  mixin let!q{ c, _, d = args[1].findSplit(-) };
  writeln(c);
  writeln(d);
   }

artur

Re: Destructured Tuple Assignment


On Friday, 15 May 2015 at 11:04:24 UTC, Per Nordlöw wrote:
I'm guessing the closest thing we can get in current D version 
is something like


let(q{first, _, second},
expression.findSplit(separator));

right?


Correction: I believe it must look like

 let!q{first, _, second}(expression.findSplit(separator));

or

 let!`first, _, second`(expression.findSplit(separator));


Is it possible to define a let that does what I want here?

If so, could someone, pleeeze, help me write out a stub for this?

I'm guessing something along the lines of

mixin template let(string vars, Ts...)
{
import std.range: splitter;

// declare variables in current scope. TODO do we need a 
mixin here?

foreach (i, var; vars.splitter(`, `))
{
mixin(Ts[i] ~ ` ` ~ var);
}

auto let(Tuple!Ts xs)
{
foreach (i, var; vars.splitter(`, `))
{
mixin(Ts[i] ~ ` = ` ~ xs[i]);
}
}
}

unittest
{
let!q{first, _, second}(tuple(`first`, `_`, `second`));
}

but this fails in many ways.

Could someone, please help out here?

Re: Destructured Tuple Assignment

2015-05-15 Thread John Colvin via Digitalmars-d-learn


On Friday, 15 May 2015 at 10:23:24 UTC, Per Nordlöw wrote:
I recall having seen an example of using some D magic (via 
mixin perhaps?) to realize tuple destructuring in assignments 
like


magic(first, _, second) = expression.findSplit(separator);

somewhere. But I can't seem to find it right now.

References anyone?

BTW :I'm aware of Kenjis PR, which I am very much longing for ;)


Well there's always this, which is a bit ugly:

typeof(expression) first, _, second;
TypeTuple!(first, _, second) = expression.findSplit(separator);

But of course the holy grail is being able to declare variables 
inline.

Re: Destructured Tuple Assignment


On Friday, 15 May 2015 at 10:23:24 UTC, Per Nordlöw wrote:
I recall having seen an example of using some D magic (via 
mixin perhaps?) to realize tuple destructuring in assignments 
like


magic(first, _, second) = expression.findSplit(separator);


I found it:

http://forum.dlang.org/thread/ubrngkdmyduepmfkh...@forum.dlang.org?page=1

I'm however still as frustrated because instead of having to 
specify tuple indexes explicitly as


 const result = expression.findSplit(separator);
 const first = result[0];
 const second = result[2];

I instead have to write types explicitly (no type-inference)

 string first, _, second; // non-generic unstable type guess
 tie(first, _, second) = expression.findSplit(separator);

or just as bad

 typeof(expression.findSplit(separator)[0]) first, _, second;
 tie(first, _, second) = expression.findSplit(separator);

Can this be solved with a mixin somehow?

Re: Destructured Tuple Assignment


On Friday, 15 May 2015 at 10:46:32 UTC, Per Nordlöw wrote:

Can this be solved with a mixin somehow?


To clarify, I want to be able to write

let(first, _, second) = expression.findSplit(separator);

without having to first declare `first`, `_` and `second`.

I'm guessing the closest thing we can get in current D version is 
something like


let(q{first, _, second},
expression.findSplit(separator));

right?

Which might be good enough for now.

Re: Destructured Tuple Assignment


On Friday, 15 May 2015 at 12:22:55 UTC, Artur Skawina wrote:

   template let(string D) {
  mixin({
 enum sdsl = D.findSplit(=);
 mixin(`struct S { int `~sdsl[0]~`; }`);
 string code = `auto v = ` ~ sdsl[2] ~ `;`;
 foreach (I, _; typeof(S.tupleof))
code ~= `auto ` ~ S.tupleof[I].stringof ~ ` = 
v[`~I.stringof~`]; `;

 return code;
  }());
   }


I added support for auto, const and immutable declarations at

https://github.com/nordlow/justd/blob/master/ties.d#L96

which allows usage as

mixin let!q{ auto i, d, s, c = tuple(42, 3.14, `pi`, 'x') };
mixin let!q{ const i, d, s, c = tuple(42, 3.14, `pi`, 'x') };
mixin let!q{ immutable i, d, s, c = tuple(42, 3.14, `pi`, 
'x') };


:)

See unittests for details

Re: Destructured Tuple Assignment


On Friday, 15 May 2015 at 12:22:55 UTC, Artur Skawina wrote:

   import std.algorithm;

   template let(string D) {
  mixin({
 enum sdsl = D.findSplit(=);
 mixin(`struct S { int `~sdsl[0]~`; }`);
 string code = `auto v = ` ~ sdsl[2] ~ `;`;
 foreach (I, _; typeof(S.tupleof))
code ~= `auto ` ~ S.tupleof[I].stringof ~ ` = 
v[`~I.stringof~`]; `;

 return code;
  }());
   }


Thanks!

Re: Destructured Tuple Assignment


On Friday, 15 May 2015 at 13:40:01 UTC, Per Nordlöw wrote:

I added support for auto, const and immutable declarations at

https://github.com/nordlow/justd/blob/master/ties.d#L96


And support for ignoring `_` as a variable as:

import std.algorithm.searching: findSplit;
mixin let!q{ c, _, d = `11-12`.findSplit(`-`) };
static assert(__traits(compiles, c == c));
static assert(!__traits(compiles, _ == _)); // assert that it 
was ignored

Re: Tuple assignment

2015-05-11 Thread Jacob Carlborg via Digitalmars-d


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 assignment

2015-05-10 Thread Walter Bright via Digitalmars-d


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 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: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 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 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.

pedant-modeassembly language file, not assembler (which is the
program to do the transformation)/pedant-mode

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

2015-05-10 Thread weaselcat via Digitalmars-d


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

2015-05-10 Thread Oren Tirosh via Digitalmars-d


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

2015-05-10 Thread Oren Tirosh via Digitalmars-d


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

2015-05-10 Thread Walter Bright via Digitalmars-d


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

2015-05-10 Thread John Colvin via Digitalmars-d


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.


pedant-modeassembly language file, not assembler (which is the
program to do the transformation)/pedant-mode

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

2015-05-10 Thread Iain Buclaw via Digitalmars-d

On 10 May 2015 at 21:41, John Colvin via Digitalmars-d
digitalmars-d@puremagic.com 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.


 pedant-modeassembly language file, not assembler (which is the
 program to do the transformation)/pedant-mode

 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

2015-05-09 Thread Walter Bright via Digitalmars-d


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.

Tuple assignment

2015-05-09 Thread Russel Winder via Digitalmars-d

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

[Issue 11314] inline ice with tuple assignment and if/else again

2013-11-07 Thread d-bugmail

https://d.puremagic.com/issues/show_bug.cgi?id=11314


Walter Bright bugzi...@digitalmars.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bugzi...@digitalmars.com
 Resolution||FIXED


-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 11314] inline ice with tuple assignment and if/else again

2013-11-04 Thread d-bugmail

http://d.puremagic.com/issues/show_bug.cgi?id=11314


Hisayuki Mima youx...@gmail.com changed:

   What|Removed |Added

   Severity|normal  |regression


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 11314] inline ice with tuple assignment and if/else again

2013-11-04 Thread d-bugmail

http://d.puremagic.com/issues/show_bug.cgi?id=11314



--- Comment #1 from Kenji Hara k.hara...@gmail.com 2013-11-04 07:21:32 PST ---
Which version did have worked correctly with? I tested 2.063 to 2.056, but all
versions causes same ICE.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 11314] inline ice with tuple assignment and if/else again

2013-11-04 Thread d-bugmail

http://d.puremagic.com/issues/show_bug.cgi?id=11314


Kenji Hara k.hara...@gmail.com changed:

   What|Removed |Added

   Keywords||ice, pull
   Severity|regression  |major


--- Comment #2 from Kenji Hara k.hara...@gmail.com 2013-11-04 17:40:32 PST ---
https://github.com/D-Programming-Language/dmd/pull/2717

I think this is not a regression issue against past releases, so change the
importance to 'major'.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 11314] New: inline ice with tuple assignment and if/else again

2013-10-21 Thread d-bugmail

http://d.puremagic.com/issues/show_bug.cgi?id=11314

   Summary: inline ice with tuple assignment and if/else again
   Product: D
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: youx...@gmail.com


--- Comment #0 from Hisayuki Mima youx...@gmail.com 2013-10-21 22:33:43 JST 
---
This bug may be related to the Issue 11223

-
module bug;
struct Tuple(T...)
{
T values;

void opAssign(typeof(this) rhs)
{
if(0)
values[] = rhs.values[];
else
assert(0);
}
}

struct S{}

void main()
{
Tuple!S t;
t = Tuple!S(S.init);
}
-
$ dmd -inline bug.d
dmd: glue.c:1281: virtual unsigned int Type::totym(): Assertion `0' failed.
-

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 11223] inline ice with tuple assignment and if/else

2013-10-12 Thread d-bugmail

http://d.puremagic.com/issues/show_bug.cgi?id=11223



--- Comment #3 from Martin Nowak c...@dawg.eu 2013-10-12 12:42:12 PDT ---
Thanks a lot for the quick fix.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 11223] inline ice with tuple assignment and if/else

2013-10-11 Thread d-bugmail

http://d.puremagic.com/issues/show_bug.cgi?id=11223


Kenji Hara k.hara...@gmail.com changed:

   What|Removed |Added

   Keywords||pull


--- Comment #1 from Kenji Hara k.hara...@gmail.com 2013-10-10 23:00:21 PDT ---
https://github.com/D-Programming-Language/dmd/pull/2653

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 11223] inline ice with tuple assignment and if/else

2013-10-11 Thread d-bugmail

http://d.puremagic.com/issues/show_bug.cgi?id=11223



--- Comment #2 from github-bugzi...@puremagic.com 2013-10-11 11:40:14 PDT ---
Commits pushed to master at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/250a8734370d223f1757c9796e284cc45a82e6ec
fix Issue 11223 - inline ice with tuple assignment and if/else

Superseded fix of 36a44cbcea9fbb18b221f77e00f2dca77f21bc88

https://github.com/D-Programming-Language/dmd/commit/9c136af1c21423a252fcf019f3aca112028667f8
Merge pull request #2653 from 9rnsr/fix11223

[REG2.064a] Issue 11223 - inline ice with tuple assignment and if/else

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 11223] inline ice with tuple assignment and if/else

2013-10-11 Thread d-bugmail

http://d.puremagic.com/issues/show_bug.cgi?id=11223


Walter Bright bugzi...@digitalmars.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bugzi...@digitalmars.com
 Resolution||FIXED


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 11223] New: inline ice with tuple assignment and if/else

2013-10-10 Thread d-bugmail

http://d.puremagic.com/issues/show_bug.cgi?id=11223

   Summary: inline ice with tuple assignment and if/else
   Product: D
   Version: D2
  Platform: All
OS/Version: All
Status: NEW
  Keywords: ice
  Severity: regression
  Priority: P4
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: c...@dawg.eu


--- Comment #0 from Martin Nowak c...@dawg.eu 2013-10-10 21:23:13 PDT ---
cat  bug.d  CODE
struct Tuple(T...)
{
T values;

void opAssign(Tuple rhs)
{
if (0)
values = rhs.values;
else
assert(0);
}
}

void bug()
{
Tuple!string tmp;
tmp = Tuple!string();
}
CODE

dmd -c -inline bug


glue.c:1265: virtual unsigned int Type::totym(): Assertion `0' failed.


I reduced that test case from the vibe.d source code. The ICE is triggered by
the opAssign in std.typecons.Tuple so this might affects a lot of code and
fixing the regression is very important.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 10179] Tuple assignment should not cause has no effect error even if the length is zero

2013-05-27 Thread d-bugmail

http://d.puremagic.com/issues/show_bug.cgi?id=10179



--- Comment #2 from github-bugzi...@puremagic.com 2013-05-27 06:19:05 PDT ---
Commits pushed to master at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/1a5c0e6f01a78a501782d1f511e0f68d85b36d6f
fix Issue 10179 - Tuple assignment should not cause has no effect error even
if the length is zero

https://github.com/D-Programming-Language/dmd/commit/ccfdf10f50e76ae93986619190a542da565388f7
Merge pull request #2084 from 9rnsr/fix10179

[enh] Issue 10179 - Tuple assignment should not cause has no effect error
even if the length is zero

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 10179] Tuple assignment should not cause has no effect error even if the length is zero

2013-05-27 Thread d-bugmail

http://d.puremagic.com/issues/show_bug.cgi?id=10179


Andrei Alexandrescu and...@erdani.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||and...@erdani.com
 Resolution||FIXED


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

Re: Tuple literal syntax + Tuple assignment

2010-10-29 Thread Bruno Medeiros


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
seewebsiteforem...@erdani.org 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 assignment

2010-10-08 Thread Jérôme M. Berger

Juanjo Alvarez wrote:
 On Thu, 07 Oct 2010 15:14:12 -0400, bearophile
 bearophileh...@lycos.com 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 stdin, line 1, in module
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

2010-10-08 Thread Juanjo Alvarez

On Fri, 08 Oct 2010 16:11:53 -0400, bearophile 
bearophileh...@lycos.com 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

2010-10-08 Thread Leandro Lucarella

Juanjo Alvarez, el  9 de octubre a las 04:02 me escribiste:
 On Fri, 08 Oct 2010 16:11:53 -0400, bearophile
 bearophileh...@lycos.com 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.

Tuple assignment

2010-10-07 Thread Walter Bright


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;

Re: Tuple assignment

2010-10-07 Thread Russel Winder

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.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

2010-10-07 Thread Walter Bright


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

2010-10-07 Thread Walter Bright


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

2010-10-07 Thread Denis Koroskin

On Thu, 07 Oct 2010 10:43:18 +0400, Russel Winder rus...@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.

Re: Tuple assignment

2010-10-07 Thread Brad Roberts

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

2010-10-07 Thread Denis Koroskin

On Thu, 07 Oct 2010 11:42:06 +0400, Brad Roberts bra...@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!

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

2010-10-07 Thread Pelle


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

2010-10-07 Thread Pelle


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 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 assignment

2010-10-07 Thread Juanjo Alvarez

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 literal syntax + Tuple assignment

2010-10-07 Thread Simen kjaeraas


bearophile bearophileh...@lycos.com 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 situations

Re: Tuple assignment

2010-10-07 Thread Leandro Lucarella

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 literal syntax + Tuple assignment

2010-10-07 Thread kenji hara

2010/10/7 bearophile bearophileh...@lycos.com:
 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 bearophilebearophileh...@lycos.com:
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-07 Thread kenji hara

2010年10月8日1:34 Andrei Alexandrescu seewebsiteforem...@erdani.org:
On 10/7/10 11:11 CDT, kenji hara wrote:
2010/10/7 bearophilebearophileh...@lycos.com:
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

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:

I understood that 'Tuple' is a generic word in math/language theory.
Withdraw my proposals.

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

2010-10-07 Thread Michel Fortin

On 2010-10-07 12:34:33 -0400, Andrei Alexandrescu 
seewebsiteforem...@erdani.org 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

2010-10-07 Thread retard

Thu, 07 Oct 2010 13:45:16 -0400, Michel Fortin wrote:

 On 2010-10-07 12:34:33 -0400, Andrei Alexandrescu
 seewebsiteforem...@erdani.org 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
seewebsiteforem...@erdani.org 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 assignment

2010-10-07 Thread Tomek Sowiński

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