http://wiki.dlang.org/DIP32

Kenji Hara

On Friday, 29 March 2013 at 08:58:06 UTC, kenji hara wrote:
> http://wiki.dlang.org/DIP32
>
> Kenji Hara

Can't tell at the first read about possible issues, but conceptually - love it, fits nicely.

29-Mar-2013 12:57, kenji hara пишет:
> http://wiki.dlang.org/DIP32
>
> Kenji Hara

A few typos like:
{c, $} = tup;   // Rewritten as: a = tup[0];
where it should be //Rewritten as c = tup[0];

About swapping values by tuple assignment.

Why not simply make this work:
{x, y} = {y, x}

By lowering
{x, y}  = {y, x};
to
auto temp0 = y;
auto temp1 = x;
x = temp0;
y = temp1;

And let the compiler do value propagation to remove the extra temp0.

Another note - is there any way to extend this notation to common structs other then .tupleof ? I think we may hopefully extended it later towards struct destructruing a-la EcmaScript 6, see

http://wiki.ecmascript.org/doku.php?id=harmony:destructuring

All in all it's a great proposal, I'm loving it.


-- 
Dmitry Olshansky

2013/3/29 Dmitry Olshansky <dmitry.olsh@gmail.com>

> A few typos like:
> {c, $} = tup;   // Rewritten as: a = tup[0];
> where it should be //Rewritten as c = tup[0];
>

Thanks. Fixed.


> About swapping values by tuple assignment.
>
> Why not simply make this work:
> {x, y} = {y, x}
>
> By lowering
> {x, y}  = {y, x};
> to
> auto temp0 = y;
> auto temp1 = x;
> x = temp0;
> y = temp1;
>
> And let the compiler do value propagation to remove the extra temp0.
>

Because it already exists.

template Seq(T...) { alias Seq = T; }
void main()
{
    int x = 1, y = 2;
    Seq!(x, y) = Seq!(y, x);    // tuple assigmnent
    assert(x == 2);
    assert(y == 2);
}

Another note - is there any way to extend this notation to common structs
> other then .tupleof ? I think we may hopefully extended it later towards struct destructruing a-la EcmaScript 6, see
>
> http://wiki.ecmascript.org/**doku.php?id=harmony:**destructuring<http://wiki.ecmascript.org/doku.php?id=harmony:destructuring>


Hmm, interesting. I'll see it later.

Kenji Hara

My first thought when I saw {} was json. This is getting a little further away from tuples, but would it be hard to add named fields to this too like json:

auto a = {"foo":12, "bar":"twelve"};

int a_foo = a.foo;
string a_bar = a[1];


The std.typecons Tuple!() can do this kind of thing too.

kenji hara:

> http://wiki.dlang.org/DIP32

Thank you Kenji for working on this :-)

Some comments on your proposal:

- - - - - - - - - - - -

> Use braces and commas. Inside tuple literal, ; never appears. So it will not be confused with lambdas and ScopeStatements.<

This is true. On the other hand it's not too much hard to forget a ; or to not see it by mistake. So please let's think well about this important design decision.

- - - - - - - - - - - -

I presume this will be valid code:

auto tup = {10, "hi", 3.14};
assert(tup[0..2] == {10, "hi"});

- - - - - - - - - - - -

One handy tuple syntax in Haskell allows you to name both the items of a tuple and it whole:


void foo(t2@{int a, string b}) {
   // here a and b are tuple items and t2 is the whole tuple.
}
auto t1@{x, y} = {10, "hi"};
foo(t1);

- - - - - - - - - - - -

auto tup = {};  // zero-element tuple (Syntax meaning will be changed!)


Nullary tuples are not that useful in D. Scala doesn't even have a short literal for them.

So a longer syntax like this is acceptable:

auto tup = Tuple();

- - - - - - - - - - - -

This is nice, so we are merging tuple types with tuples, this will simplify D language:

// declare tuple value by using explicit tuple type
{int, string} tup = {1, "hi"};

 alias TL = {int, string[], double[string]};  // types


But one thing to remember in the document is that here T1 and T2 are different, because your tuples do not auto-flatten as TypeTuples currently do:

alias T1 = {float, double, real};
alias T2 = {float, double, {real}};

- - - - - - - - - - - -

foreach (Float; {float, double, real}) { ... }

I think you meant to put a variable name there.

- - - - - - - - - - - -

    {1}         // one-element tuple

I presume this too will be accepted as 1-tuple:

    {1,}

- - - - - - - - - - - -

{c, $} = tup;   // Rewritten as: c = tup[0];

$ is used for array lengths, so it's not so good to overload it to mean "don't care" too.


Alternative syntaxes:

{c, $_} = tup;
{c, @} = tup;
{c, @_} = tup;
{c, $$} = tup;
{c, {}} = tup;
{c, {_}} = tup;
{c, $~} = tup;
{c, @~= tup;
etc.

- - - - - - - - - - - -

if (auto {1, y} = tup) {
    // If the first element of tup (tup[0]) is equal to 1,
    // y captures the second element of tup (tup[1]).
}


I suggest to leave that pattern matching plus conditional to a future refinement of tuple implementation (a second stage. And remove it from this first stage proposal. So I suggest to split your proposal in two successive proposals). It seems handy, but D programmers need some time to go there.

- - - - - - - - - - - -

switch (tup) {
    case {1, 2}:
    case {$, 2}:
    case {1, x}:    // capture tup[1] into 'x' when tup[0] == 1
    default:        // same as {...}
}


What's quite important here is the "final switch". D has to make sure you are considering all possible cases.

- - - - - - - - - - - -

I suggest to leave this to the second stage, and remove it from this proposal:

auto tup = {1, "hi", 3.14, [1,2,3]};
if (auto {1, "hi", ...} = tup) {}

- - - - - - - - - - - -

"will" is written badly:

// If the first element of coord is equal to 1 (== x), 'then' statement wil be evaluated.


- - - - - - - - - - - -

I think this is the third thing to leave to the second stage:


int x = 1;
if (auto {$x, y} = coord) { ... }

- - - - - - - - - - - -

This is nice:

if (auto {x, y} = coord[]) {}   // same, explicitly expands fields

- - - - - - - - - - - -

This is handy and it's vaguely present in Python3, but I suggest to leave this (4th thing) to the second stage:

if (auto {num, msg, ...} = tup) {}      // ok, `...` matches to zero-elements.

- - - - - - - - - - - -

Bye,
bearophile

Adam D. Ruppe:

> auto a = {"foo":12, "bar":"twelve"};
>
> int a_foo = a.foo;
> string a_bar = a[1];
>
>
> The std.typecons Tuple!() can do this kind of thing too.

I think Tuple!() has them mostly because there is no handy syntax to unpack them.

Tuples with field names are records.

Bye,
bearophile

> {c, {}} = tup;

This can't be used, because having an empty tuple as second tuple item is valid.


> {c, @~= tup;

That was:

{c, @~} tup;

Bye,
bearophile

On Fri, 29 Mar 2013 13:56:08 +0100, bearophile <bearophileHUGS@lycos.com> wrote:

> One handy tuple syntax in Haskell allows you to name both the items of a tuple and it whole:
>
>
> void foo(t2@{int a, string b}) {
>     // here a and b are tuple items and t2 is the whole tuple.
> }
> auto t1@{x, y} = {10, "hi"};
> foo(t1);

I suggest instead this syntax:

auto {x, y} t1 = {10, "hi"};

It's closer to regular D syntax.


> foreach (Float; {float, double, real}) { ... }
>
> I think you meant to put a variable name there.

foreach (Type; {float, double, real}) { ... }

See it now?


> - - - - - - - - - - - -
>
> {c, $} = tup;   // Rewritten as: c = tup[0];
>
> $ is used for array lengths, so it's not so good to overload it to mean "don't care" too.
>
> Alternative syntaxes:
>
> {c, $_} = tup;
> {c, @} = tup;
> {c, @_} = tup;
> {c, $$} = tup;
> {c, {}} = tup;
> {c, {_}} = tup;
> {c, $~} = tup;
> {c, @~= tup;
> etc.

... has been introduced to match zero or more elements for pattern matching
already. I see no reason not to use ... for this.

-- 
Simen

On 03/29/2013 09:57 AM, kenji hara wrote:
> http://wiki.dlang.org/DIP32
>
> Kenji Hara

Looks quite nice. I especially like the {a, b} => ... thing.

I think, however, that there are a handful serious flaws that need to be addressed:

0 "Inside tuple literal, ; never appears."
  {{;}}           // a tuple not matching your specification
  {{if(foo()){}}} // a non-tuple matching your specification

1 "Note: Cannot swap values by tuple assignment."
  IMO a no-go. The syntax is too accessible to introduce this kind of
  pitfall.

2 "// Error: cannnot use $ inside a function literal"
  That's a DMD-ism presumably stemming from laziness during "fixing" of
  an ICE/wrong code bug or something. I'd hate to carry this over to
  the spec. Don't rely on it. The disambiguation is arbitrary, but may
  be necessary. (It's not like it is a case actually occurring in real
  code.)

3 Unpacking / pattern matching is underspecified.
  - Do patterns nest?
  - Which right-hand sides are allowed with which semantics?
  - Which left-hand sides are allowed with which semantics?
    eg, what about:
      ref int foo() { ... }
      { foo(), foo() } = {1, 2};

4 There is no way to capture the part matched by "..."

5 .expand (or similar) property is missing.

6 Relation to {a: 2, b: 3}-style struct literals not explained.

7 Tuple unpacking for template parameters not mentioned.


Is there a migration path for Phobos tuples planned?

Eg. template Tuple(T...){ alias Tuple = {T}; }
    (field spec parsing left out for illustration)