Tuple unpacking syntax [Was: Re: Multiple return values...]
Andrei Alexandrescu: > Let me put it another way: I don't see one syntax over another a deal > maker or deal breaker. At all. I am usually able to follow threads, but this time I am a bit lost (this discussion has mixed very different topics like ABIs, implementation efficiency of tuples and typetuples, a hypothetical not-really-a-tuple third-kind of tuple, built-in syntax, library implementation code, etc). Is someone able and willing to summarize the current situation of this discussion? >From the last weeks (more like months) of intensive usage of functional-style >D code I really think D will really enjoy an unpacking syntax for >std.typecons.Tuples. Recently I have written a long post about this: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=159627 The proposed syntax is quite simple, it's mostly implemented in a patch. The person that has written the patch says he's willing to add the missing part, for foreach looping (see below). Walter is waiting for something, to find problems. One raw solution for this impasse is to apply the patch as an experiment and then look for problems. Practical usages helps thinking, sometimes. In this thread I have seen something regarding problems of the patch on code like this, that has one already defined variable: Tuple!(int,int) foo() { return tuple(1, 2); } int x; (x, int y) = foo(); If such code is a problem for the patch, then I am sure the patch author will improve it. Now I am seeing a scatter()/gather library implementation. In that post of mine there examples like: alias Tuple!(CTable, string, int, int) Four; GrowableCircularQueue!Four open; // ... while (open.length) { immutable item = open.pop(); immutable CTable cur = item[0]; immutable string cSol = item[1]; immutable int x = item[2]; immutable int y = item[3]; With a tuple unpacking syntax becomes: while (open.length) { immutable (cur, cSol, x, y) = open.pop(); Are those scatter/gather designed to solve this very very simple problem? How do you unpack into immutables? I don't understand. The missing part in the DMD patch is for something like this (but the exact syntax for this is not yet decided): foreach (auto (x, y); [tuple(1,2), tuple(3,4)]) {...} How do you do this with library code? So I think we should put this thread back on the rails. Library implementations are not enough here. I suggest to start discussing about what's wrong in the proposed D syntax patch, solve the problems Walter has with it. Bye, bearophile
Re: Tuple unpacking syntax [Was: Re: Multiple return values...]
Maybe [x, y] = func(); ?
Re: Tuple unpacking syntax [Was: Re: Multiple return values...]
On Tuesday, 13 March 2012 at 22:26:14 UTC, bearophile wrote: Andrei Alexandrescu: Let me put it another way: I don't see one syntax over another a deal maker or deal breaker. At all. I am usually able to follow threads, but this time I am a bit lost (this discussion has mixed very different topics like ABIs, implementation efficiency of tuples and typetuples, a hypothetical not-really-a-tuple third-kind of tuple, built-in syntax, library implementation code, etc). Is someone able and willing to summarize the current situation of this discussion? [snip] So I think we should put this thread back on the rails. Library implementations are not enough here. I suggest to start discussing about what's wrong in the proposed D syntax patch, solve the problems Walter has with it. Bye, bearophile Yeap, I'm confused as well. D's tuple support seems to be completely messed up. This reminds me - what was the semantic problem with the auto unpacking in a function's parameter list? Personally, I think D ought to learn from the experts on this. Take a look at how FP languages implement this. E.g take a look at ML or Haskell for pointers.
Re: Tuple unpacking syntax [Was: Re: Multiple return values...]
Kind of unrelated but I think that it is important to have a way to ignore values also. Leaving them bank would sufice. (int i,,float f) = intBoringFloat();
Re: Tuple unpacking syntax [Was: Re: Multiple return values...]
On Wed, 14 Mar 2012 13:33:18 +1100, Kevin Cox wrote: Kind of unrelated but I think that it is important to have a way to ignore values also. Leaving them bank would sufice. (int i,,float f) = intBoringFloat(); For what its worth, the Euphoria Programming Language uses ? to signify ignored values. eg. integer i atomf {i, ?, f} = intBoringFloat() We felt that leaving a blank could be a source of human error (can be missed when reading code) and also a result of human error (accidentally put in a double comma). Using an unusual glyph to signify omission was the compromise we came up with. -- Derek Parnell
Re: Tuple unpacking syntax [Was: Re: Multiple return values...]
I'm encouraged to see that every person in this thread so far seems to feel the same way as me regarding the syntax. On 14 March 2012 05:25, Derek Parnell wrote: > On Wed, 14 Mar 2012 13:33:18 +1100, Kevin Cox > wrote: > >> (int i,,float f) = intBoringFloat(); >> > > For what its worth, the Euphoria Programming Language uses ? to signify > ignored values. > Yeah I tend to agree with that logic. I was quite liking the '_' that someone suggested much earlier in the thread: «x, _, int y» = intBoringFloat (); // Note: it seems to be unclear which brackets to use ;) Hey, the Japanese have some really cool brackets! 「x, _, int y」 = ... 〖x, _, int y〗 = ... 〘x, _, int y〙 = ... Tight! ;)
Re: Tuple unpacking syntax [Was: Re: Multiple return values...]
On Wednesday, 14 March 2012 at 02:33:29 UTC, Kevin Cox wrote: Kind of unrelated but I think that it is important to have a way to ignore values also. Leaving them bank would sufice. (int i,,float f) = intBoringFloat(); or (int i, null, float f) = intBoringFloat(); or (int i, void, float f) = intBoringFloat();
Re: Tuple unpacking syntax [Was: Re: Multiple return values...]
On Wed, 14 Mar 2012 03:52:55 -0500, Manu wrote: I'm encouraged to see that every person in this thread so far seems to feel the same way as me regarding the syntax. On 14 March 2012 05:25, Derek Parnell wrote: On Wed, 14 Mar 2012 13:33:18 +1100, Kevin Cox wrote: (int i,,float f) = intBoringFloat(); For what its worth, the Euphoria Programming Language uses ? to signify ignored values. Yeah I tend to agree with that logic. I was quite liking the '_' that someone suggested much earlier in the thread: «x, _, int y» = intBoringFloat (); // Note: it seems to be unclear which brackets to use ;) Hey, the Japanese have some really cool brackets! 「x, _, int y」 = ... 〖x, _, int y〗 = ... 〘x, _, int y〙 = ... Tight! ;) UTF math has a bunch of cool brackets as well ⟦ x, _, int y ⟧ ⦃ x, _, int y ⦄ ⦅ x, _, int y ⦆ ⦇ x, _, int y ⦈ ⦉ x, _, int y ⦊ But there's a reason we use /// instead of ⫻; we shouldn't require custom keyboard mappings in order to program efficiently in D.
Re: Tuple unpacking syntax [Was: Re: Multiple return values...]
On 14 March 2012 15:17, Robert Jacques wrote: > But there's a reason we use /// instead of ⫻; we shouldn't require custom > keyboard mappings in order to program efficiently in D. > Hold that thought, I think you're missing a major franchising opportunity right there... D branded 'pro-codah' keyboards! Nice! :P
Re: Tuple unpacking syntax [Was: Re: Multiple return values...]
On Wednesday, 14 March 2012 at 13:17:47 UTC, Robert Jacques wrote: But there's a reason we use /// instead of ⫻; we shouldn't require custom keyboard mappings in order to program efficiently in D. Aren't we supposed to be moving towards more natural interfaces in computing? I'm sure that once the touch interface is perfected for text input it would be trivial to have a "coding keyboard" or a "D keyboard". The keyboard mappings would simply come bundled with the compiler. The current text based programming is quite limiting considering that we actually deal with a tree of tokens. IDEs already manipulate code at the AST level in order to enable refactoring. The next logical step would be to eliminate the text form all together and store code at the AST level, thus avoiding lexing/parsing overhead and the limits of text based representation. e.g. subtextual.org has cool ideas how to design such a future non textual language. For example, representing Boolean logic in a table instead of arbitrary nested if statements.