www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - uniform tuple syntax

reply "Vlad Levenfeld" <vlevenfeld gmail.com> writes:
Anything going on with this? Been looking forward to seeing it 
for awhile.
Mar 24 2015
next sibling parent reply Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 03/24/2015 03:11 PM, Vlad Levenfeld wrote:

 Anything going on with this? Been looking forward to seeing it for awhile.


I think we should settle on a syntax and split DIP32 in a tuple part and
a pattern matching part.
The proposal wasn't yet formally accepted, partly because we wanted to
wait, whether more needs come up. By now it's already 2 years old and it
still looks complete IMO.

http://wiki.dlang.org/DIP32
Mar 24 2015
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 24 March 2015 at 18:12:03 UTC, Martin Nowak wrote:

 wait, whether more needs come up. By now it's already 2 years 
 old and it
 still looks complete IMO.

 http://wiki.dlang.org/DIP32


Using "$" for something completely different is confusing, but it 

can be automated.
Mar 24 2015
prev sibling next sibling parent reply "Vlad Levenfeld" <vlevenfeld gmail.com> writes:
On Tuesday, 24 March 2015 at 18:12:03 UTC, Martin Nowak wrote:

 I think we should settle on a syntax and split DIP32 in a tuple 
 part and
 a pattern matching part.
 The proposal wasn't yet formally accepted, partly because we 
 wanted to
 wait, whether more needs come up. By now it's already 2 years 
 old and it
 still looks complete IMO.

 http://wiki.dlang.org/DIP32


Anything wrong with using {}? It looks good to me, does it lead 
to any parsing ambiguities?

I just want to get all the .tuple and .expand and tuple parameter 
function overload litter out of my code. My use cases are 
multiple returns and parameters-first UFCS. It'd be great if

   {arg1, arg2}.func1.func2;

matched the signature

   auto func1 (T,U)(T arg1, U arg2);

On Tuesday, 24 March 2015 at 18:38:51 UTC, Ola Fosheim Grøstad 
wrote:

 Using "$" for something completely different is confusing, but 
 it looks ok. Maybe rename existing use of "$" for length to 



You'd also have to rename opDollar to opHash or, maybe less 
confusingly, opPound. Also, $ is already a common idiom (at least 
in Unix) for "the end". It would be better to just name the
Mar 24 2015
next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 24 March 2015 at 23:07:29 UTC, Vlad Levenfeld wrote:

 On Tuesday, 24 March 2015 at 18:12:03 UTC, Martin Nowak wrote:

 I think we should settle on a syntax and split DIP32 in a 
 tuple part and
 a pattern matching part.
 The proposal wasn't yet formally accepted, partly because we 
 wanted to
 wait, whether more needs come up. By now it's already 2 years 
 old and it
 still looks complete IMO.

 http://wiki.dlang.org/DIP32


 Anything wrong with using {}? It looks good to me, does it lead 
 to any parsing ambiguities?


This syntax is over over loaded.
Mar 24 2015
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Tuesday, 24 March 2015 at 23:07:29 UTC, Vlad Levenfeld wrote:

 Anything wrong with using {}? It looks good to me, does it lead 
 to any parsing ambiguities?


In this context, it would look like a delegate/function literal 
or perhaps the start of a scope in other contexts.

auto a = { arg1, arg2 }; // a is a function pointer, not a tuple
  // ( that won't compile cuz of a missing semicolon inside but 
still )

{ int }

would look like a block scope. Again, it wouldn't compile because 
the int is missing an identifier, but still, it would pose a 
parsing problem.
Mar 24 2015
prev sibling next sibling parent "Brian Schott" <briancschott gmail.com> writes:
On Tuesday, 24 March 2015 at 23:07:29 UTC, Vlad Levenfeld wrote:

 Anything wrong with using {}? It looks good to me, does it lead 
 to any parsing ambiguities?


Before:
auto x = {}; // struct or function?

After:
auto x = {}; // struct, function, or tuple??
Mar 24 2015
prev sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 24 March 2015 at 23:07:29 UTC, Vlad Levenfeld wrote:

 You'd also have to rename opDollar to opHash or, maybe less 
 confusingly, opPound.


opLength?


 Also, $ is already a common idiom (at least in Unix) for "the 
 end". It would be better to just name


No, in Unix "$" is used in /bin/sh for the prompt and to denote a 

"${#variable}" is used for length. What you are thinking about is 
that "$" is used for pattern matching of the conceptual 
EOL-symbol (character) in regular expressions, but that's not 
length.
So in the Unix world "$" is either used for variables or pattern 



the length operator? Using "$" for length is just confusing if 
you know other languages.
Mar 25 2015
prev sibling next sibling parent "ixid" <nuaccount gmail.com> writes:
On Tuesday, 24 March 2015 at 18:12:03 UTC, Martin Nowak wrote:

 On 03/24/2015 03:11 PM, Vlad Levenfeld wrote:

 Anything going on with this? Been looking forward to seeing it 
 for awhile.


 I think we should settle on a syntax and split DIP32 in a tuple 
 part and
 a pattern matching part.
 The proposal wasn't yet formally accepted, partly because we 
 wanted to
 wait, whether more needs come up. By now it's already 2 years 
 old and it
 still looks complete IMO.

 http://wiki.dlang.org/DIP32


What was the conclusion about parens tuples? They would be much 
prettier.
Mar 24 2015
prev sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 25/03/2015 7:11 a.m., Martin Nowak wrote:

 On 03/24/2015 03:11 PM, Vlad Levenfeld wrote:

 Anything going on with this? Been looking forward to seeing it for awhile.


 I think we should settle on a syntax and split DIP32 in a tuple part and
 a pattern matching part.
 The proposal wasn't yet formally accepted, partly because we wanted to
 wait, whether more needs come up. By now it's already 2 years old and it
 still looks complete IMO.

 http://wiki.dlang.org/DIP32


There is one thing blatantly missing atleast to me.
Unpacking into function arguments.

void myfunc(int x, string y) {
	// ...
}

myfunc({1, "hi!"}.unpack);

Lua has something along these lines for tables. And it is a real hit. Of 
course .unpack probably isn't needed, but hey it makes it more explicit.
Mar 24 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/24/15 8:00 PM, Rikki Cattermole wrote:

 On 25/03/2015 7:11 a.m., Martin Nowak wrote:

 On 03/24/2015 03:11 PM, Vlad Levenfeld wrote:

 Anything going on with this? Been looking forward to seeing it for
 awhile.


 I think we should settle on a syntax and split DIP32 in a tuple part and
 a pattern matching part.
 The proposal wasn't yet formally accepted, partly because we wanted to
 wait, whether more needs come up. By now it's already 2 years old and it
 still looks complete IMO.

 http://wiki.dlang.org/DIP32


 There is one thing blatantly missing atleast to me.
 Unpacking into function arguments.

 void myfunc(int x, string y) {
      // ...
 }

 myfunc({1, "hi!"}.unpack);


myfunc(tuple(1, "hi!").expand);

Andrei
Mar 24 2015
next sibling parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 25/03/2015 5:13 p.m., Andrei Alexandrescu wrote:

 On 3/24/15 8:00 PM, Rikki Cattermole wrote:

 On 25/03/2015 7:11 a.m., Martin Nowak wrote:

 On 03/24/2015 03:11 PM, Vlad Levenfeld wrote:

 Anything going on with this? Been looking forward to seeing it for
 awhile.


 I think we should settle on a syntax and split DIP32 in a tuple part and
 a pattern matching part.
 The proposal wasn't yet formally accepted, partly because we wanted to
 wait, whether more needs come up. By now it's already 2 years old and it
 still looks complete IMO.

 http://wiki.dlang.org/DIP32


 There is one thing blatantly missing atleast to me.
 Unpacking into function arguments.

 void myfunc(int x, string y) {
      // ...
 }

 myfunc({1, "hi!"}.unpack);


 myfunc(tuple(1, "hi!").expand);

 Andrei


In that case, +1 on my vote for being complete.
Mar 24 2015
prev sibling parent "Vlad Levenfeld" <vlevenfeld gmail.com> writes:
On Wednesday, 25 March 2015 at 04:13:03 UTC, Andrei Alexandrescu 
wrote:

 On 3/24/15 8:00 PM, Rikki Cattermole wrote:

 There is one thing blatantly missing atleast to me.
 Unpacking into function arguments.

 void myfunc(int x, string y) {
     // ...
 }

 myfunc({1, "hi!"}.unpack);


 myfunc(tuple(1, "hi!").expand);

 Andrei


Yeah, treating the builtin tuple the same way as, say, a 
TypeTuple, would be cool. For everything else, there's the 
library tuple. I've noticed that I can do

   TypeTuple!(arg1, arg2, arg3).func;

but this only works if the args are symbols (which can be 
aliased), but not for expressions. What I'd really like is to say

   {2 + 4, `he` ~ `llo`}.myfunc;

Without an explicit "tuple" or "expand". Also, putting something 
into a library tuple forces a copy, but I think it'd be nice if 
the symbols in builtin tuples could be ref. In other words, make 
{} mean roughly the same thing as TypeTuple (which have a 
misleading name as they can be used for everything, not just 
types, which is why I rename TypeTuple to Cons in my code).

On Tuesday, 24 March 2015 at 23:57:53 UTC, Adam D. Ruppe wrote:

 In this context, it would look like a delegate/function literal 
 or perhaps the start of a scope in other contexts.

 auto a = { arg1, arg2 }; // a is a function pointer, not a tuple
  // ( that won't compile cuz of a missing semicolon inside but 
 still )

 { int }

 would look like a block scope. Again, it wouldn't compile 
 because the int is missing an identifier, but still, it would 
 pose a parsing problem.


So, the first case should be a tuple. As a function, {} means the 
same thing as (){}. I don't really like this, and never use this 
{} notation anyway, because my syntax highlighting chokes on it. 
In any case, requiring an argument list before a function 
definition would resolve the ambiguity.

In any case, the issue would come to light the moment "a" was 
actually used. "Tuples don't overload opCall" or something. Or it 
might get caught by some type-checking logic before that. Unless 
"a" were never used, in which case it doesn't really matter what 
it resolves to (unless it were being declared specifically to be 
stored or in TMP, in which case naming the explicit type is a 
better practice anyway).

As for the second, it should just be a TypeTuple, if anything. If 
that's not possible, then its an error. As for which error, I'd 
say its safe to assume its a scope and give the "no identifier" 
error.

On Tuesday, 24 March 2015 at 23:59:20 UTC, Brian Schott wrote:

 Before:
 auto x = {}; // struct or function?

 After:
 auto x = {}; // struct, function, or tuple??


For the before case, it's gotta be a function, because it doesn't 
make sense to use a brace-enclosed initializer without any type 
information.

The "after" case should be interpreted as a tuple, for reasons 
outlined above.
Mar 24 2015
prev sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Vlad Levenfeld:


 Anything going on with this? Been looking forward to seeing it 
 for awhile.


It will happen.

Bye,
bearophile
Mar 25 2015