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 ddparn...@bigpond.com wrote: On Wed, 14 Mar 2012 13:33:18 +1100, Kevin Cox kevincox...@gmail.com 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 turkey...@gmail.com 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 ddparn...@bigpond.com wrote: On Wed, 14 Mar 2012 13:33:18 +1100, Kevin Cox kevincox...@gmail.com 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 sandf...@jhu.edu 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: snip 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.
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.Darticle_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...]
On Wed, 14 Mar 2012 13:33:18 +1100, Kevin Cox kevincox...@gmail.com
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
