www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Better lambdas!!!!!!!!!!

reply "Prudence" <Pursuit Happyness.All> writes:
How bout this:

void myfunc(double delegate(int i, int z, float f)) {....}


myfunc((int i, int z, float f) { return i*z*f; } }

vs

myfunc({ return i*z*f; })   // Names of parameters are inferred 
from signature.


by specifying the parameter names in the signature, we don't have 
to specify them in the lamba creation. This doesn't replace the 
original way, just adds the ability to infer the names if they 
are not specified.

Of course, this hides the names outside the lambda, but a warning 
could be issued(no different than if one does it explicitly.
Sep 10 2015
next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 10 September 2015 at 17:55:06 UTC, Prudence wrote:
 void myfunc(double delegate(int i, int z, float f)) {....}


 myfunc((int i, int z, float f) { return i*z*f; } }
You could also write `myfunc((i,z,f) => i*z*f);` right now. The names are easy to do.
Sep 10 2015
prev sibling next sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 09/10/2015 10:55 AM, Prudence wrote:
 How bout this:

 void myfunc(double delegate(int i, int z, float f)) {....}


 myfunc((int i, int z, float f) { return i*z*f; } }

 vs

 myfunc({ return i*z*f; })   // Names of parameters are inferred from
 signature.
Considering other features of the language, that's pretty much impossible in D. What if there is another i in scope: int i; myfunc({ return i*z*f; }); Now, should it call another overload of myfunc that takes (int z, int f) because i is something else? Should the compiler analyze the body of the code and decide which symbols could be parameters? And then go through all overloads of myfunc? etc.? Ali
Sep 10 2015
parent reply "Prudence" <Pursuit Happyness.All> writes:
On Thursday, 10 September 2015 at 18:02:36 UTC, Ali Çehreli wrote:
 On 09/10/2015 10:55 AM, Prudence wrote:
 How bout this:

 void myfunc(double delegate(int i, int z, float f)) {....}


 myfunc((int i, int z, float f) { return i*z*f; } }

 vs

 myfunc({ return i*z*f; })   // Names of parameters are
inferred from
 signature.
Considering other features of the language, that's pretty much impossible in D. What if there is another i in scope: int i; myfunc({ return i*z*f; }); Now, should it call another overload of myfunc that takes (int z, int f) because i is something else? Should the compiler analyze the body of the code and decide which symbols could be parameters? And then go through all overloads of myfunc? etc.? Ali
As I said, it could throw a warning or error. It, in some sense, is already a a problem with nested blocks that hide outside variables, is it not? The compiler doesn't need to scan anything. It knows the which parameters from the definition! -> void myfunc(double delegate(int i, int z, float f)) <- Compiler knows to use the names here as the default names in for the parameters when. when used: myfunc({ return i*z*f; }); <- Oh, there are the names, we know what they are because the signature is tells us. The compiler does the following: 1. Sees we have a block without any parameters defined. i.e., a lambda. 2. It looks up the signature of myfunc to find out what the names are 3. It sees that they are i z and f 4. Now it knows and it effectively rewrites the code as myfunc((i,z,f) { return i*z*f; }); Surely this is not difficult, 4 steps?
Sep 11 2015
parent reply "Pierre Krafft" <kpierre+dlang outlook.com> writes:
On Saturday, 12 September 2015 at 01:03:54 UTC, Prudence wrote:
 On Thursday, 10 September 2015 at 18:02:36 UTC, Ali Çehreli 
 wrote:
 On 09/10/2015 10:55 AM, Prudence wrote:
 How bout this:

 void myfunc(double delegate(int i, int z, float f)) {....}


 myfunc((int i, int z, float f) { return i*z*f; } }

 vs

 myfunc({ return i*z*f; })   // Names of parameters are
inferred from
 signature.
Considering other features of the language, that's pretty much impossible in D. What if there is another i in scope: int i; myfunc({ return i*z*f; }); Now, should it call another overload of myfunc that takes (int z, int f) because i is something else? Should the compiler analyze the body of the code and decide which symbols could be parameters? And then go through all overloads of myfunc? etc.? Ali
As I said, it could throw a warning or error. It, in some sense, is already a a problem with nested blocks that hide outside variables, is it not? The compiler doesn't need to scan anything. It knows the which parameters from the definition! -> void myfunc(double delegate(int i, int z, float f)) <- Compiler knows to use the names here as the default names in for the parameters when. when used: myfunc({ return i*z*f; }); <- Oh, there are the names, we know what they are because the signature is tells us. The compiler does the following: 1. Sees we have a block without any parameters defined. i.e., a lambda. 2. It looks up the signature of myfunc to find out what the names are 3. It sees that they are i z and f 4. Now it knows and it effectively rewrites the code as myfunc((i,z,f) { return i*z*f; }); Surely this is not difficult, 4 steps?
You're making your code more brittle for a small gain. The suggestion makes parameter usage order important and the compiler can't warn about my typos. Consider: myfunc({return "x:"~x~"y:"-y;}) getting changed to myfunc({return "y:"~y~"x:"~x;}); Or the typo in myfunc({return i*z+f*j;}); Lambdas are already very concise. This proposal doesn't give any benefits outside of very simple lambdas. Such lambdas are already so simple that they could use some standard functions instead (like sum, to!T, and bind).
Sep 11 2015
parent reply "Prudence" <Pursuit Happyness.All> writes:
On Saturday, 12 September 2015 at 02:13:11 UTC, Pierre Krafft 
wrote:
 On Saturday, 12 September 2015 at 01:03:54 UTC, Prudence wrote:
 On Thursday, 10 September 2015 at 18:02:36 UTC, Ali Çehreli 
 wrote:
 On 09/10/2015 10:55 AM, Prudence wrote:
 How bout this:

 void myfunc(double delegate(int i, int z, float f)) {....}


 myfunc((int i, int z, float f) { return i*z*f; } }

 vs

 myfunc({ return i*z*f; })   // Names of parameters are
inferred from
 signature.
Considering other features of the language, that's pretty much impossible in D. What if there is another i in scope: int i; myfunc({ return i*z*f; }); Now, should it call another overload of myfunc that takes (int z, int f) because i is something else? Should the compiler analyze the body of the code and decide which symbols could be parameters? And then go through all overloads of myfunc? etc.? Ali
As I said, it could throw a warning or error. It, in some sense, is already a a problem with nested blocks that hide outside variables, is it not? The compiler doesn't need to scan anything. It knows the which parameters from the definition! -> void myfunc(double delegate(int i, int z, float f)) <- Compiler knows to use the names here as the default names in for the parameters when. when used: myfunc({ return i*z*f; }); <- Oh, there are the names, we know what they are because the signature is tells us. The compiler does the following: 1. Sees we have a block without any parameters defined. i.e., a lambda. 2. It looks up the signature of myfunc to find out what the names are 3. It sees that they are i z and f 4. Now it knows and it effectively rewrites the code as myfunc((i,z,f) { return i*z*f; }); Surely this is not difficult, 4 steps?
You're making your code more brittle for a small gain. The suggestion makes parameter usage order important and the compiler can't warn about my typos. Consider: myfunc({return "x:"~x~"y:"-y;}) getting changed to myfunc({return "y:"~y~"x:"~x;}); Or the typo in myfunc({return i*z+f*j;}); Lambdas are already very concise. This proposal doesn't give any benefits outside of very simple lambdas. Such lambdas are already so simple that they could use some standard functions instead (like sum, to!T, and bind).
What does this have to do with my proposal? Those issues exist regardless of the simplification. myfunc({return "x:"~x~"y:"-y;}) getting changed to myfunc({return "y:"~y~"x:"~x;}); huh? What do you mean the suggestion makes parameter usage order important? They are important, it has nothing to do with the suggestion? Are you saying that you want to reserve the right to do something like myfunc(string delegate(string x, string y)); and myfunc((y,x){ "y:"~y~"x:"~x; }) ? If so, or unless I'm missing something, that's bad no matter what. Changing the order and reversing the names is more than just confusing, it's hard to read and most people will gloss over that fact. Be consistent with your parameters and maybe you'll have less bugs? Or the typo in myfunc({return i*z+f*j;}); Again, what does this have to do with anything? A typo is a typo and is always a mistake. The above example has the same effect regardless if the parameters are explicit or deduced. myfunc((i,z,f) {return i*z+f*j;}); j is still a problem. If j is defined outside the lambda then regardless of specific or implicit parameter names, it will not cause any problems. In either case, the compiler can see that j is either referenced outside the scope or undefined. It has nothing to do with the parameters used. Of course maybe I'm missing something, but essentially are not almost all uses of lambda's simply copying the parameter signature of the delegate. It already infers types... you could say that leads to typo's too...
Sep 11 2015
parent reply "Pierre Krafft" <kpierre+dlang outlook.com> writes:
On Saturday, 12 September 2015 at 03:32:51 UTC, Prudence wrote:
 On Saturday, 12 September 2015 at 02:13:11 UTC, Pierre Krafft 
 wrote:
 On Saturday, 12 September 2015 at 01:03:54 UTC, Prudence wrote:
 On Thursday, 10 September 2015 at 18:02:36 UTC, Ali Çehreli 
 wrote:
 On 09/10/2015 10:55 AM, Prudence wrote:
 How bout this:

 void myfunc(double delegate(int i, int z, float f)) {....}


 myfunc((int i, int z, float f) { return i*z*f; } }

 vs

 myfunc({ return i*z*f; })   // Names of parameters are
inferred from
 signature.
Considering other features of the language, that's pretty much impossible in D. What if there is another i in scope: int i; myfunc({ return i*z*f; }); Now, should it call another overload of myfunc that takes (int z, int f) because i is something else? Should the compiler analyze the body of the code and decide which symbols could be parameters? And then go through all overloads of myfunc? etc.? Ali
As I said, it could throw a warning or error. It, in some sense, is already a a problem with nested blocks that hide outside variables, is it not? The compiler doesn't need to scan anything. It knows the which parameters from the definition! -> void myfunc(double delegate(int i, int z, float f)) <- Compiler knows to use the names here as the default names in for the parameters when. when used: myfunc({ return i*z*f; }); <- Oh, there are the names, we know what they are because the signature is tells us. The compiler does the following: 1. Sees we have a block without any parameters defined. i.e., a lambda. 2. It looks up the signature of myfunc to find out what the names are 3. It sees that they are i z and f 4. Now it knows and it effectively rewrites the code as myfunc((i,z,f) { return i*z*f; }); Surely this is not difficult, 4 steps?
You're making your code more brittle for a small gain. The suggestion makes parameter usage order important and the compiler can't warn about my typos. Consider: myfunc({return "x:"~x~"y:"-y;}) getting changed to myfunc({return "y:"~y~"x:"~x;}); Or the typo in myfunc({return i*z+f*j;}); Lambdas are already very concise. This proposal doesn't give any benefits outside of very simple lambdas. Such lambdas are already so simple that they could use some standard functions instead (like sum, to!T, and bind).
What does this have to do with my proposal? Those issues exist regardless of the simplification. myfunc({return "x:"~x~"y:"-y;}) getting changed to myfunc({return "y:"~y~"x:"~x;}); huh? What do you mean the suggestion makes parameter usage order important? They are important, it has nothing to do with the suggestion? Are you saying that you want to reserve the right to do something like myfunc(string delegate(string x, string y)); and myfunc((y,x){ "y:"~y~"x:"~x; }) ? If so, or unless I'm missing something, that's bad no matter what. Changing the order and reversing the names is more than just confusing, it's hard to read and most people will gloss over that fact. Be consistent with your parameters and maybe you'll have less bugs? Or the typo in myfunc({return i*z+f*j;}); Again, what does this have to do with anything? A typo is a typo and is always a mistake. The above example has the same effect regardless if the parameters are explicit or deduced. myfunc((i,z,f) {return i*z+f*j;}); j is still a problem. If j is defined outside the lambda then regardless of specific or implicit parameter names, it will not cause any problems. In either case, the compiler can see that j is either referenced outside the scope or undefined. It has nothing to do with the parameters used. Of course maybe I'm missing something, but essentially are not almost all uses of lambda's simply copying the parameter signature of the delegate. It already infers types... you could say that leads to typo's too...
myfunc({return "x:"~x~"y:"-y;}); is infered to mean myfunc((x,y){return "x:"~x~"y:"-y;}); while myfunc({return "y:"~y~"x:"~x;}); is infered to mean myfunc((y,x){return "y:"~y~"x:"~x;}); which is not what I expect since the lambda I want is myfunc((x,y){return "y:"~y~"x:"~x;}); This can lead to subtle bugs which are very hard to see. In the typo example there could be two overloaded functions differing only in that one takes a delegate having 3 parameters and one taking a delegate having 4 parameters. If we explicitly write the lambda parameters the typo will be found since j is undefined. But when parameters are inferred the compiler will see that {return i*z + f*j;} matches the function taking a lambda with 4 parameters. Inferred parameter types are on the brink of what I can allow. They can risk typos, but not as easily since you write the parameters twice (declaration and usage). They can also silently change if the function taking the delegate has the parameter type changed. I don't want to add more magic to that area.
Sep 12 2015
next sibling parent "Idan Arye" <GenericNPC gmail.com> writes:
On Saturday, 12 September 2015 at 10:44:05 UTC, Pierre Krafft 
wrote:
  myfunc({return "x:"~x~"y:"-y;});
 is infered to mean myfunc((x,y){return "x:"~x~"y:"-y;});
 while
  myfunc({return "y:"~y~"x:"~x;});
 is infered to mean myfunc((y,x){return "y:"~y~"x:"~x;});
 which is not what I expect since the lambda I want is 
 myfunc((x,y){return "y:"~y~"x:"~x;});
 This can lead to subtle bugs which are very hard to see.
I don't think this is what the OP was suggesting. As far as I understand, the suggestion was that the lambda's arguments would be inferred from the function argument in higher order's function signature - not from the ones used in the lambda's body as you suggest. So, `myfunc` will be declared as: void myfunc(string delegate(string x, string y)) { // ... And when the compiler see `myfunc({return "x:"~x~"y:"-y;});`, it'll see that `x` and `y` appear in the function argument's definition and match them accordingly. This means that `myfunc({/*...*/})` will be inferred to `myfunc((x,y) {/*...*/})` no matter what the order of argument usage in the lambda's body is - because in the function's signature the arguments are `x` and `y` in that order.
Sep 12 2015
prev sibling parent "Prudence" <Pursuit Happyness.All> writes:
On Saturday, 12 September 2015 at 10:44:05 UTC, Pierre Krafft 
wrote:
 On Saturday, 12 September 2015 at 03:32:51 UTC, Prudence wrote:
 On Saturday, 12 September 2015 at 02:13:11 UTC, Pierre Krafft 
 wrote:
 On Saturday, 12 September 2015 at 01:03:54 UTC, Prudence 
 wrote:
 On Thursday, 10 September 2015 at 18:02:36 UTC, Ali Çehreli 
 wrote:
 On 09/10/2015 10:55 AM, Prudence wrote:
 How bout this:

 void myfunc(double delegate(int i, int z, float f)) {....}


 myfunc((int i, int z, float f) { return i*z*f; } }

 vs

 myfunc({ return i*z*f; })   // Names of parameters are
inferred from
 signature.
Considering other features of the language, that's pretty much impossible in D. What if there is another i in scope: int i; myfunc({ return i*z*f; }); Now, should it call another overload of myfunc that takes (int z, int f) because i is something else? Should the compiler analyze the body of the code and decide which symbols could be parameters? And then go through all overloads of myfunc? etc.? Ali
As I said, it could throw a warning or error. It, in some sense, is already a a problem with nested blocks that hide outside variables, is it not? The compiler doesn't need to scan anything. It knows the which parameters from the definition! -> void myfunc(double delegate(int i, int z, float f)) <- Compiler knows to use the names here as the default names in for the parameters when. when used: myfunc({ return i*z*f; }); <- Oh, there are the names, we know what they are because the signature is tells us. The compiler does the following: 1. Sees we have a block without any parameters defined. i.e., a lambda. 2. It looks up the signature of myfunc to find out what the names are 3. It sees that they are i z and f 4. Now it knows and it effectively rewrites the code as myfunc((i,z,f) { return i*z*f; }); Surely this is not difficult, 4 steps?
You're making your code more brittle for a small gain. The suggestion makes parameter usage order important and the compiler can't warn about my typos. Consider: myfunc({return "x:"~x~"y:"-y;}) getting changed to myfunc({return "y:"~y~"x:"~x;}); Or the typo in myfunc({return i*z+f*j;}); Lambdas are already very concise. This proposal doesn't give any benefits outside of very simple lambdas. Such lambdas are already so simple that they could use some standard functions instead (like sum, to!T, and bind).
What does this have to do with my proposal? Those issues exist regardless of the simplification. myfunc({return "x:"~x~"y:"-y;}) getting changed to myfunc({return "y:"~y~"x:"~x;}); huh? What do you mean the suggestion makes parameter usage order important? They are important, it has nothing to do with the suggestion? Are you saying that you want to reserve the right to do something like myfunc(string delegate(string x, string y)); and myfunc((y,x){ "y:"~y~"x:"~x; }) ? If so, or unless I'm missing something, that's bad no matter what. Changing the order and reversing the names is more than just confusing, it's hard to read and most people will gloss over that fact. Be consistent with your parameters and maybe you'll have less bugs? Or the typo in myfunc({return i*z+f*j;}); Again, what does this have to do with anything? A typo is a typo and is always a mistake. The above example has the same effect regardless if the parameters are explicit or deduced. myfunc((i,z,f) {return i*z+f*j;}); j is still a problem. If j is defined outside the lambda then regardless of specific or implicit parameter names, it will not cause any problems. In either case, the compiler can see that j is either referenced outside the scope or undefined. It has nothing to do with the parameters used. Of course maybe I'm missing something, but essentially are not almost all uses of lambda's simply copying the parameter signature of the delegate. It already infers types... you could say that leads to typo's too...
myfunc({return "x:"~x~"y:"-y;}); is infered to mean myfunc((x,y){return "x:"~x~"y:"-y;}); while myfunc({return "y:"~y~"x:"~x;}); is infered to mean myfunc((y,x){return "y:"~y~"x:"~x;}); which is not what I expect since the lambda I want is myfunc((x,y){return "y:"~y~"x:"~x;}); This can lead to subtle bugs which are very hard to see. In the typo example there could be two overloaded functions differing only in that one takes a delegate having 3 parameters and one taking a delegate having 4 parameters. If we explicitly write the lambda parameters the typo will be found since j is undefined. But when parameters are inferred the compiler will see that {return i*z + f*j;} matches the function taking a lambda with 4 parameters. Inferred parameter types are on the brink of what I can allow. They can risk typos, but not as easily since you write the parameters twice (declaration and usage). They can also silently change if the function taking the delegate has the parameter type changed. I don't want to add more magic to that area.
I agree that they do conceal some things, but that is the nature of stuff. To claim it is wrong to do that is like saying auto is wrong because it too has the same issues. auto func() { return typeX; } later on, change it to typeY and then your screwed, it can also suffer from typos: auto func() { int t = 0; void *j; return j; // oops, typo, I meant t. } It just sounds like you are trying avoid all possible programmer faults... but that makes for weak programmers. Weaking the language for the lowest common denominator stagnates progress. Look out the American education system for a prime example. It's not the way to go, which has been proven time and time again. It's known as laziness. For me, I can look at the signature once and know the order and names. Regardless, no one is taking away your training wheels. I'm not saying replace the current syntax. I'm not sure why everyone pretends they are forced to use the syntactic sugar, If you have diabetes, don't use it!
Sep 12 2015
prev sibling next sibling parent reply "anonymous" <a b.cd> writes:
On Thursday, 10 September 2015 at 17:55:06 UTC, Prudence wrote:
 Of course, this hides the names outside the lambda, but a 
 warning could be issued(no different than if one does it 
 explicitly.
This makes the parameter names part of the API. The author of a library is unable to rename parameter without breaking user code. I do not believe the benefit is large enough to accept such a drawback.
Sep 10 2015
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, 10 September 2015 at 18:05:43 UTC, anonymous wrote:
 On Thursday, 10 September 2015 at 17:55:06 UTC, Prudence wrote:
 Of course, this hides the names outside the lambda, but a 
 warning could be issued(no different than if one does it 
 explicitly.
This makes the parameter names part of the API. The author of a library is unable to rename parameter without breaking user code. I do not believe the benefit is large enough to accept such a drawback.
That's one of the main reasons that I hate the idea of named arguments. It's more stuff that's part of the API, more public stuff that you have to name correctly and risk bikeshedding arguments over, and more stuff that can you can't change without breaking existing code. - Jonathan M Davis
Sep 10 2015
next sibling parent "wobbles" <grogan.colin gmail.com> writes:
On Thursday, 10 September 2015 at 18:23:52 UTC, Jonathan M Davis 
wrote:
 On Thursday, 10 September 2015 at 18:05:43 UTC, anonymous wrote:
 On Thursday, 10 September 2015 at 17:55:06 UTC, Prudence wrote:
 Of course, this hides the names outside the lambda, but a 
 warning could be issued(no different than if one does it 
 explicitly.
This makes the parameter names part of the API. The author of a library is unable to rename parameter without breaking user code. I do not believe the benefit is large enough to accept such a drawback.
That's one of the main reasons that I hate the idea of named arguments. It's more stuff that's part of the API, more public stuff that you have to name correctly and risk bikeshedding arguments over, and more stuff that can you can't change without breaking existing code. - Jonathan M Davis
+1
Sep 10 2015
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 09/10/2015 08:23 PM, Jonathan M Davis wrote:
 That's one of the main reasons that I hate the idea of named arguments.
 It's more stuff that's part of the API, more public stuff that you have
 to name correctly and risk bikeshedding arguments over, and more stuff
 that can you can't change without breaking existing code.

 - Jonathan M Davis
Note that parameter names can already be determined by user code using reflection.
Sep 11 2015
parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, 11 September 2015 at 20:16:42 UTC, Timon Gehr wrote:
 On 09/10/2015 08:23 PM, Jonathan M Davis wrote:
 That's one of the main reasons that I hate the idea of named 
 arguments.
 It's more stuff that's part of the API, more public stuff that 
 you have
 to name correctly and risk bikeshedding arguments over, and 
 more stuff
 that can you can't change without breaking existing code.

 - Jonathan M Davis
Note that parameter names can already be determined by user code using reflection.
True, but as soon as you're doing much with reflection, all bets are off anyway, because it often becomes trivial to break code by making small changes. And I think that it's pretty clear at this point that you can't expect parameter names to not change, since they're not part of the function signature (even if compile-time reflection does let you get at them), which would not be the case if we had named arguments. - Jonathan M Davis
Sep 11 2015
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-09-10 20:23, Jonathan M Davis wrote:

 That's one of the main reasons that I hate the idea of named arguments.
In Ruby named arguments need to be explicitly requested when declaring a method: def bar(a) a == { a: 3 } # A hash (associative array) end def foo(a:) a == 3 end foo(a: 3) bar(a: 3) Not supplying the name of the parameter in the call to "foo" would result in an error. I think named arguments like this is way, _way_ more superior that the ridiculous idea of using an enum instead of a bool. -- /Jacob Carlborg
Sep 12 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Saturday, 12 September 2015 at 14:40:05 UTC, Jacob Carlborg 
wrote:
 Not supplying the name of the parameter in the call to "foo" 
 would result in an error.
Python has similar semantics. Very useful to force explicitness when you have complex changing APIs that have many parameters of the same type "add_row(string,string,string,string,string,string)" But it is a bit different than using named variables in a lambda, since in the lambda case it will shadow local variables.
Sep 12 2015
prev sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 10 September 2015 at 17:55:06 UTC, Prudence wrote:
 by specifying the parameter names in the signature, we don't 
 have to specify them in the lamba creation. This doesn't 
 replace the original way, just adds the ability to infer the 
 names if they are not specified.

 Of course, this hides the names outside the lambda, but a 
 warning could be issued(no different than if one does it 
 explicitly.
How about just having numbered parameters like this: { $2 < ($1*$2) }
Sep 10 2015
next sibling parent reply "Meta" <jared771 gmail.com> writes:
On Thursday, 10 September 2015 at 19:37:53 UTC, Ola Fosheim 
Grøstad wrote:
 How about just having numbered parameters like this:

 { $2 < ($1*$2) }
What about this situation? [[1, 2], [3, 4], [5, 6]].reduce!{ auto localMax = { $1 > $2 ? $1 : $2; } auto first = $1.reduce!localMax; auto second = $2.reduce!localMax; return first > second ? first : second; } How can the compiler tell which $1 and $2 is which? What if one wants to access both the outer $1 and the inner $1 in localMax?
Sep 10 2015
next sibling parent "Meta" <jared771 gmail.com> writes:
On Thursday, 10 September 2015 at 20:10:49 UTC, Meta wrote:
 On Thursday, 10 September 2015 at 19:37:53 UTC, Ola Fosheim 
 Grøstad wrote:
 How about just having numbered parameters like this:

 { $2 < ($1*$2) }
What about this situation? [[1, 2], [3, 4], [5, 6]].reduce!{ auto localMax = { $1 > $2 ? $1 : $2; } auto first = $1.reduce!localMax; auto second = $2.reduce!localMax; return first > second ? first : second; } How can the compiler tell which $1 and $2 is which? What if one wants to access both the outer $1 and the inner $1 in localMax?
Should be `return first > second ? $1 : $2`, but you get the idea.
Sep 10 2015
prev sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 10 September 2015 at 20:10:49 UTC, Meta wrote:
 How can the compiler tell which $1 and $2 is which? What if one 
 wants to access both the outer $1 and the inner $1 in localMax?
If there is a conflict you should use a regular lambda on the outer one?
Sep 10 2015
parent reply "Meta" <jared771 gmail.com> writes:
On Thursday, 10 September 2015 at 20:56:58 UTC, Ola Fosheim 
Grøstad wrote:
 If there is a conflict you should use a regular lambda on the 
 outer one?
You could, but then doesn't that defeat the point a bit? My example was off-the-cuff, but the point is that we already have a fairly concise lambda syntax, and adding a new type will mean that we have 4 different ways of expressing the same lambda function. It's just not really worth it.
Sep 10 2015
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 10 September 2015 at 21:03:12 UTC, Meta wrote:
 On Thursday, 10 September 2015 at 20:56:58 UTC, Ola Fosheim 
 Grøstad wrote:
 If there is a conflict you should use a regular lambda on the 
 outer one?
You could, but then doesn't that defeat the point a bit? My example was off-the-cuff, but the point is that we already have a fairly concise lambda syntax, and adding a new type will mean that we have 4 different ways of expressing the same lambda function. It's just not really worth it.
Yes, it is usually it is a bad idea to have many ways to do things. A numbered schema probably should only be used in an innermost scope as a single expression, so if you see "$1" you know the definition stops at the brackets. Apropos one way of doing things: http://www.ozonehouse.com/mark/periodic/ :D
Sep 10 2015
prev sibling next sibling parent "Idan Arye" <GenericNPC gmail.com> writes:
On Thursday, 10 September 2015 at 21:03:12 UTC, Meta wrote:
 On Thursday, 10 September 2015 at 20:56:58 UTC, Ola Fosheim 
 Grøstad wrote:
 If there is a conflict you should use a regular lambda on the 
 outer one?
You could, but then doesn't that defeat the point a bit? My example was off-the-cuff, but the point is that we already have a fairly concise lambda syntax, and adding a new type will mean that we have 4 different ways of expressing the same lambda function. It's just not really worth it.
Clojure solved this by disallowing nesting lambdas-with-numbered-arguments: Clojure 1.7.0 user=> (#(+ %1 %2) 1 2) 3 user=> (#(#(+ %1 %2) %2 %1) 1 2) IllegalStateException Nested #()s are not allowed clojure.lang.LispReader$FnReader.invoke (LispReader.java:703) #object[clojure.core$_PLUS_ 0x10fde30a "clojure.core$_PLUS_ 10fde30a"] CompilerException java.lang.RuntimeException: Unable to resolve symbol: %1 in this context, compiling:(NO_SOURCE_PATH:0:0) CompilerException java.lang.RuntimeException: Unable to resolve symbol: %2 in this context, compiling:(NO_SOURCE_PATH:0:0) RuntimeException Unmatched delimiter: ) clojure.lang.Util.runtimeException (Util.java:221) CompilerException java.lang.RuntimeException: Unable to resolve symbol: %2 in this context, compiling:(NO_SOURCE_PATH:0:0) CompilerException java.lang.RuntimeException: Unable to resolve symbol: %1 in this context, compiling:(NO_SOURCE_PATH:0:0) RuntimeException Unmatched delimiter: ) clojure.lang.Util.runtimeException (Util.java:221) 1 2 RuntimeException Unmatched delimiter: ) clojure.lang.Util.runtimeException (Util.java:221) Than again, Clojure never was a big advocate of the one-way-of-doing-things approach... At any rate, since string lambdas can usually be used in place of this syntax, and in the cases string lambdas can't be used(because you need something from the scope) it's not THAT hard to use proper lambdas - I see no reason to support it.
Sep 10 2015
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2015-09-10 23:03, Meta wrote:

 You could, but then doesn't that defeat the point a bit?
No, I don't think it does. For example in Scala you can do like this: foo(_ < _) Which would be the same as: foo((a, b) a < b) But if you want to use the same parameter more than once then you cannot use the first syntax. -- /Jacob Carlborg
Sep 12 2015
prev sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 10 September 2015 at 19:37:53 UTC, Ola Fosheim 
Grøstad wrote:
 How about just having numbered parameters like this:

 { $2 < ($1*$2) }
The string lambdas Phobos supports basically does this: `b < a*b` would work in there. These are falling out of favor with the new syntax in the language, but they are still supported by most the library.
Sep 10 2015
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 10 September 2015 at 20:51:18 UTC, Adam D. Ruppe 
wrote:
 The string lambdas Phobos supports basically does this:

 `b < a*b`

 would work in there. These are falling out of favor with the 
 new syntax in the language, but they are still supported by 
 most the library.
Isn't that a string mixin? Or?
Sep 10 2015
prev sibling parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, 2015-09-10 at 20:51 +0000, Adam D. Ruppe via Digitalmars-d
wrote:
 [=E2=80=A6]
=20
 The string lambdas Phobos supports basically does this:
=20
 `b < a*b`
=20
 would work in there. These are falling out of favor with the new=20
 syntax in the language, but they are still supported by most the=20
 library.
And until some bugs get fixed, you have to use string functions in some places, you cannot use proper function literals :-( --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Sep 11 2015
parent reply "ZombineDev" <valid_email he.re> writes:
On Friday, 11 September 2015 at 08:02:21 UTC, Russel Winder wrote:
 On Thu, 2015-09-10 at 20:51 +0000, Adam D. Ruppe via 
 Digitalmars-d wrote:
 […]
 
 The string lambdas Phobos supports basically does this:
 
 `b < a*b`
 
 would work in there. These are falling out of favor with the 
 new syntax in the language, but they are still supported by 
 most the library.
And until some bugs get fixed, you have to use string functions in some places, you cannot use proper function literals :-(
Can you elaborate? Are those bugs logged somewhere?
Sep 11 2015
parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 2015-09-11 at 11:32 +0000, ZombineDev via Digitalmars-d wrote:
 On Friday, 11 September 2015 at 08:02:21 UTC, Russel Winder wrote:
 On Thu, 2015-09-10 at 20:51 +0000, Adam D. Ruppe via=20
 Digitalmars-d wrote:
 [=E2=80=A6]
=20
 The string lambdas Phobos supports basically does this:
=20
 `b < a*b`
=20
 would work in there. These are falling out of favor with the=20
 new syntax in the language, but they are still supported by=20
 most the library.
=20 And until some bugs get fixed, you have to use string functions=20 in some places, you cannot use proper function literals :-(
=20 Can you elaborate? Are those bugs logged somewhere?
For example https://issues.dlang.org/show_bug.cgi?id=3D5710 The affects a number of the std.parallelism functions :-( --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Sep 11 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 11 September 2015 at 11:44:13 UTC, Russel Winder wrote:
 For example https://issues.dlang.org/show_bug.cgi?id=5710
If C++ interop is still important, maybe it would be a good idea to adopt C++ style lambdas.
Sep 11 2015
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, 11 September 2015 at 20:25:19 UTC, Ola Fosheim Grøstad 
wrote:
 On Friday, 11 September 2015 at 11:44:13 UTC, Russel Winder 
 wrote:
 For example https://issues.dlang.org/show_bug.cgi?id=5710
If C++ interop is still important, maybe it would be a good idea to adopt C++ style lambdas.
How would that help with interop? Even if we supported passing a lambda to C++ code, the syntax wouldn't need to match, just the semantics, and that could be done without adopting C++ style lambdas in D. However, given the complexity of C++ templates, as I understand it, there are no plans to ever support them in C++ interop (since it would pretty much mean putting a C++ compiler in the D compiler), in which case, there's no need to worry about C++ lambdas anyway, because they all involve templates. So, while C++ interop is important, and it's gotten some major improvements in the process of switching to D for the compiler front-end (and will likely continue to get improvements), there are still some pretty severe limits on what we're going to be able to do if we don't want to put a full C++ compiler inside of the D compiler, and we really don't want to be doing that. - Jonathan M Davis
Sep 11 2015
parent "Ola Fosheim Grostad" <ola.fosheim.grostad+dlang gmail.com> writes:
On Friday, 11 September 2015 at 23:15:58 UTC, Jonathan M Davis 
wrote:
 style lambdas in D. However, given the complexity of C++ 
 templates, as I understand it, there are no plans to ever 
 support them in C++ interop (since it would pretty much mean 
 putting a C++ compiler in the D compiler), in which case, 
 there's no need to worry about C++ lambdas anyway, because they 
 all involve templates.
No, you have to generate c++ sourcecode. No need to build in the compiler.
Sep 11 2015