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 looks ok. Maybe rename existing use of "$" for length to "#"? 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 
 "#"? It can be automated.
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 pattern matching symbol # instead.
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, but "$#" is used for the number of parameters and "${#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 matching, and "#" is used for length. In perl "$#" is used to denote last item in list? In Lua "#" is 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