www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Breaking ";" rule with lambda functions

reply pascal111 <judas.the.messiah.111 gmail.com> writes:
We all know the strange syntax of lambda function within filter 
algorithm like "auto r = chain(a, b).filter!(a => a > 0);". My 
note is, don't we break D rules by leaving ";" after lambda 
function syntax?!

Many of D rules are taken from C, we know that, so a general 
basic rule is to put ";" after each statement, so the previous 
statement of filter should be "auto r = chain(a, b).filter!(a => 
a > 0;);"? Why D leaves ";" in this case?
Aug 01 2022
next sibling parent reply ag0aep6g <anonymous example.com> writes:
On Monday, 1 August 2022 at 14:15:31 UTC, pascal111 wrote:

 Many of D rules are taken from C, we know that, so a general 
 basic rule is to put ";" after each statement, so the previous 
 statement of filter should be "auto r = chain(a, b).filter!(a 
 => a > 0;);"? Why D leaves ";" in this case?


`a => a > 0` is not a statement. It's an expression.
Aug 01 2022
parent reply pascal111 <judas.the.messiah.111 gmail.com> writes:
On Monday, 1 August 2022 at 14:34:45 UTC, ag0aep6g wrote:

 On Monday, 1 August 2022 at 14:15:31 UTC, pascal111 wrote:

 Many of D rules are taken from C, we know that, so a general 
 basic rule is to put ";" after each statement, so the previous 
 statement of filter should be "auto r = chain(a, b).filter!(a 
 => a > 0;);"? Why D leaves ";" in this case?


 `a => a > 0` is not a statement. It's an expression.


But it is still a "function", and functions make statements!! 
It's not a normal expression.
Aug 01 2022
parent reply ag0aep6g <anonymous example.com> writes:
On Monday, 1 August 2022 at 14:39:17 UTC, pascal111 wrote:

 On Monday, 1 August 2022 at 14:34:45 UTC, ag0aep6g wrote:


[...]

 `a => a > 0` is not a statement. It's an expression.


 But it is still a "function", and functions make statements!! 
 It's not a normal expression.


It's a normal expression.

`foo => bar` is an expression that doesn't involve any statement. 
So there's no semicolon.

`(foo) { return bar; }` does contain a return statement. As you 
expect, there's a semicolon. But it's still an expression like 
any other.
Aug 01 2022
parent reply pascal111 <judas.the.messiah.111 gmail.com> writes:
On Monday, 1 August 2022 at 14:46:33 UTC, ag0aep6g wrote:

 On Monday, 1 August 2022 at 14:39:17 UTC, pascal111 wrote:

 On Monday, 1 August 2022 at 14:34:45 UTC, ag0aep6g wrote:


 [...]

 `a => a > 0` is not a statement. It's an expression.


 But it is still a "function", and functions make statements!! 
 It's not a normal expression.


 It's a normal expression.

 `foo => bar` is an expression that doesn't involve any 
 statement. So there's no semicolon.

 `(foo) { return bar; }` does contain a return statement. As you 
 expect, there's a semicolon. But it's still an expression like 
 any other.


If `foo => bar` == `(foo) { return bar; }`, then  `foo => bar` is 
a function. "=>" is not an operator, it's a special symbol for 
lambda "function".

If A == B, so A's types is the same of B's type. How can it be 
withstanding `foo => bar` == `foo => bar` == `(foo) { return bar; 
}` and `foo => bar` is an expression and the other is a 
function?!! no sense.
Aug 01 2022
next sibling parent reply ag0aep6g <anonymous example.com> writes:
On Monday, 1 August 2022 at 14:52:03 UTC, pascal111 wrote:

 If `foo => bar` == `(foo) { return bar; }`, then  `foo => bar` 
 is a function. "=>" is not an operator, it's a special symbol 
 for lambda "function".

 If A == B, so A's types is the same of B's type. How can it be 
 withstanding `foo => bar` == `foo => bar` == `(foo) { return 
 bar; }` and `foo => bar` is an expression and the other is a 
 function?!! no sense.


`foo => bar` and `(foo) { return bar; }` are both function 
literals, and they're both expressions. The concepts are not 
mutually exclusive.
Aug 01 2022
parent reply pascal111 <judas.the.messiah.111 gmail.com> writes:
On Monday, 1 August 2022 at 15:08:04 UTC, ag0aep6g wrote:

 On Monday, 1 August 2022 at 14:52:03 UTC, pascal111 wrote:

 If `foo => bar` == `(foo) { return bar; }`, then  `foo => bar` 
 is a function. "=>" is not an operator, it's a special symbol 
 for lambda "function".

 If A == B, so A's types is the same of B's type. How can it be 
 withstanding `foo => bar` == `foo => bar` == `(foo) { return 
 bar; }` and `foo => bar` is an expression and the other is a 
 function?!! no sense.


 `foo => bar` and `(foo) { return bar; }` are both function 
 literals, and they're both expressions. The concepts are not 
 mutually exclusive.


Surely, because it seems that you are real man, your word must be 
taken. Isn't `(foo) { return bar; }` an anonymous function or am 
I a wrong?!! It IS a function, not an expression.
Aug 01 2022
parent reply ag0aep6g <anonymous example.com> writes:
On Monday, 1 August 2022 at 15:31:51 UTC, pascal111 wrote:

 Surely, because it seems that you are real man, your word must 
 be taken. Isn't `(foo) { return bar; }` an anonymous function 
 or am I a wrong?!! It IS a function, not an expression.


It's both an anonymous function and an expression. I don't know 
why you think it can't be both.
Aug 01 2022
parent reply pascal111 <judas.the.messiah.111 gmail.com> writes:
On Monday, 1 August 2022 at 15:39:06 UTC, ag0aep6g wrote:

 On Monday, 1 August 2022 at 15:31:51 UTC, pascal111 wrote:

 Surely, because it seems that you are real man, your word must 
 be taken. Isn't `(foo) { return bar; }` an anonymous function 
 or am I a wrong?!! It IS a function, not an expression.


 It's both an anonymous function and an expression. I don't know 
 why you think it can't be both.


Nice that you still prove it to me. I thought something will 
happen to me in my life or area as a punishment from GOD who is 
watching everything because my insisting they are functions.

You didn't say before that they are both functions!!

But how can we accept that both are functions and expressions at 
the same time and we know that expressions can be used to build 
functions themselves?!! I think they are not the same.
Aug 01 2022
parent reply ag0aep6g <anonymous example.com> writes:
On Monday, 1 August 2022 at 15:52:34 UTC, pascal111 wrote:

 But how can we accept that both are functions and expressions 
 at the same time and we know that expressions can be used to 
 build functions themselves?!! I think they are not the same.


This is getting ridiculous. I'm out.
Aug 01 2022
parent pascal111 <judas.the.messiah.111 gmail.com> writes:
On Monday, 1 August 2022 at 16:00:50 UTC, ag0aep6g wrote:

 On Monday, 1 August 2022 at 15:52:34 UTC, pascal111 wrote:

 But how can we accept that both are functions and expressions 
 at the same time and we know that expressions can be used to 
 build functions themselves?!! I think they are not the same.


 This is getting ridiculous. I'm out.


I'm not reading your mind, and you are not reading my mind and 
expecting wrongly what I think in. We are discussing an important 
point here. The question is simple "why there's no ";" in lambda 
functions syntax?!!"
Aug 01 2022
prev sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Monday, 1 August 2022 at 14:52:03 UTC, pascal111 wrote:

 If `foo => bar` == `(foo) { return bar; }`, then  `foo => bar` 
 is a function. "=>" is not an operator, it's a special symbol 
 for lambda "function".

 If A == B, so A's types is the same of B's type. How can it be 
 withstanding `foo => bar` == `foo => bar` == `(foo) { return 
 bar; }` and `foo => bar` is an expression and the other is a 
 function?!! no sense.


 From [the relevant section of the language spec:][1]


 FunctionLiterals (also known as Lambdas) enable embedding 
 anonymous functions and anonymous delegates directly into 
 expressions. [...]  The type of a function literal is a 
 delegate or a pointer to function.


In other words, a function literal is an expression that 
evaluates to either a delegate or a function pointer.

You are correct that, strictly speaking, it is wrong to say that 
a function literal "is" an anonymous function (rather than 
"refers to" or "points to" one). However, the distinction usually 
does not matter in practice, so most D programmers use the terms 
interchangeably.

[1]: https://dlang.org/spec/expression.html#function_literals
Aug 01 2022
parent reply pascal111 <judas.the.messiah.111 gmail.com> writes:
On Monday, 1 August 2022 at 19:32:41 UTC, Paul Backus wrote:

 On Monday, 1 August 2022 at 14:52:03 UTC, pascal111 wrote:

 [...]


 From [the relevant section of the language spec:][1]


 [...]


 In other words, a function literal is an expression that 
 evaluates to either a delegate or a function pointer.


I'm not sure I'm understanding this, but it seems ok;


 You are correct that, strictly speaking, it is wrong to say 
 that a function literal "is" an anonymous function (rather than 
 "refers to" or "points to" one). However, the distinction 
 usually does not matter in practice, so most D programmers use 
 the terms interchangeably.

 [1]: https://dlang.org/spec/expression.html#function_literals


My complaint is about that a function is not a same as an 
expression that functions return values, but expressions being 
evaluated to provide values.
Aug 01 2022
parent reply Ivan Kazmenko <gassa mail.ru> writes:
On Monday, 1 August 2022 at 20:36:12 UTC, pascal111 wrote:

 My complaint is about that a function is not a same as an 
 expression that functions return values, but expressions being 
 evaluated to provide values.


An analogy.

With a ternary expression, we write:
`x = (cond ? a : b);`
The traditional look of it is:
`if (cond) x = a; else x = b;`
Note how we have a semicolon after `x = a` in the latter form, 
but can't have it in the former.

Ivan Kazmenko.
Aug 01 2022
parent pascal111 <judas.the.messiah.111 gmail.com> writes:
On Monday, 1 August 2022 at 21:35:19 UTC, Ivan Kazmenko wrote:

 On Monday, 1 August 2022 at 20:36:12 UTC, pascal111 wrote:

 My complaint is about that a function is not a same as an 
 expression that functions return values, but expressions being 
 evaluated to provide values.


 An analogy.

 With a ternary expression, we write:
 `x = (cond ? a : b);`
 The traditional look of it is:
 `if (cond) x = a; else x = b;`
 Note how we have a semicolon after `x = a` in the latter form, 
 but can't have it in the former.

 Ivan Kazmenko.


Ok! it's not reasonable that you are all wrong and I'm the only 
right. I think I agree now with you that (maybe) lambda function 
is an expression. :)
Aug 01 2022
prev sibling next sibling parent reply frame <frame86 live.com> writes:
On Monday, 1 August 2022 at 14:15:31 UTC, pascal111 wrote:

 We all know the strange syntax of lambda function within filter 
 algorithm like "auto r = chain(a, b).filter!(a => a > 0);". My 
 note is, don't we break D rules by leaving ";" after lambda 
 function syntax?!

 Many of D rules are taken from C, we know that, so a general 
 basic rule is to put ";" after each statement, so the previous 
 statement of filter should be "auto r = chain(a, b).filter!(a 
 => a > 0;);"? Why D leaves ";" in this case?


In C ";" is a termination character, in D is more like to 
separate statements.

The lexer wouldn't need ";" for most cases like JavaScript and 
the expression syntax without ";" is better to read anyway.

However, the common settlement is to require a ";" where it makes 
logical sense and where it's still needed for the lexer. So we 
have this.
Aug 01 2022
parent pascal111 <judas.the.messiah.111 gmail.com> writes:
On Monday, 1 August 2022 at 17:01:33 UTC, frame wrote:

 On Monday, 1 August 2022 at 14:15:31 UTC, pascal111 wrote:

 [...]


 In C ";" is a termination character, in D is more like to 
 separate statements.

 The lexer wouldn't need ";" for most cases like JavaScript and 
 the expression syntax without ";" is better to read anyway.

 However, the common settlement is to require a ";" where it 
 makes logical sense and where it's still needed for the lexer. 
 So we have this.


It can be consider as a tolerance with traditional rules. The 
compiler won't accept lambda function with a ";", so I have to 
leave it.
Aug 01 2022
prev sibling parent reply Andrey Zherikov <andrey.zherikov gmail.com> writes:
On Monday, 1 August 2022 at 14:15:31 UTC, pascal111 wrote:

 We all know the strange syntax of lambda function within filter 
 algorithm like "auto r = chain(a, b).filter!(a => a > 0);".


TBH I don't find lambda syntax strange - it's pretty nice and 
there are two forms (unlike in C++): short one (`a => a > 0`) and 
long one (`(a) { return a > 0; }`).

Compare to C++ lambda syntax: `[](auto a) { return a > 0; }`


 My note is, don't we break D rules by leaving ";" after lambda 
 function syntax?!


There is no breakage: `a => a > 0` in this example is a 
(template) parameter to `filter` function. You can rewrite it in 
different ways, like: `filter!((a) { return a > 0; })` or

```d
alias criteria = (a) { return a > 0; };
auto r = chain(a, b).filter!criteria;
```

or even longer:

```d
auto criteria(T)(T a)
{
     return a > 0;
}

auto r = chain(a, b).filter!criteria;
```


 Many of D rules are taken from C, we know that, so a general 
 basic rule is to put ";" after each statement


I think this is more or less correct but I personally like that I 
don't need to put ";" after definition of a class or struct 
unlike in C.


 so the previous statement of filter should be "auto r = 
 chain(a, b).filter!(a => a > 0;);"? Why D leaves ";" in this 
 case?


No. it should not. The statement here is `auto r = chain(a, 
b).filter!(a => a > 0);`, not `a => a > 0`. If you use longer 
version of lambda syntax then yes, you'll see ";" there: `auto r 
= chain(a, b).filter!((a) { return a > 0; });` but ";" is not 
after lambda function, it's inside because you have `{...}` 
function body (which, I believe, is defined as a sequence of 
statements so you have ";" there).

Again, both `a => a > 0` and `(a) { return a > 0; }` are just 
parameters to `filter` function. Parameters are not terminated 
with ";". This is the same as in C - you are not adding ";" after 
function parameter:
```cpp
auto is_even = [](int i){ return i%2 == 0; };
auto result = std::find(..., ..., is_even);
```
Aug 02 2022
parent reply pascal111 <judas.the.messiah.111 gmail.com> writes:
On Tuesday, 2 August 2022 at 11:27:05 UTC, Andrey Zherikov wrote:

 On Monday, 1 August 2022 at 14:15:31 UTC, pascal111 wrote:

 [...]


 TBH I don't find lambda syntax strange - it's pretty nice and 
 there are two forms (unlike in C++): short one (`a => a > 0`) 
 and long one (`(a) { return a > 0; }`).

 [...]


Maybe I'd wrong beliefs about lambda function. It's already in 
C++, so it's a traditional feature but the problem is that I 
didn't use it before because I didn't study C++ yet.
Aug 02 2022
parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 8/2/22 09:40, pascal111 wrote:


 Maybe I'd wrong beliefs about lambda function. It's already in C++, so
 it's a traditional feature


Lambdas are a common feature of many programming languages. C++ got 
lambdas in their C++11 release, many years after D and many other 
languages had them. (It is not common for the C++ community to give 
credit. Most of their features are presented as C++ inventions when they 
are not. For example, almost the entirety of the C++11 features already 
existed in D (and other languages before D).)


 but the problem is that I didn't use it
 before because I didn't study C++ yet.


C++ is the new-kid-in-the-block when it comes to lambdas.

Getting back to lambda syntax, you don't have to use the shorthand => 
syntax. I try to explain how various syntaxes relate to each other:

   http://ddili.org/ders/d.en/lambda.html#ix_lambda.function,%20lambda

My book is freely available and I think is better than the documentation 
you've shown earlier, which apparently included copies of my text:

   http://ddili.org/ders/d.en/index.html

You can find most of your questions about keywords and syntax in the 
index section:

   http://ddili.org/ders/d.en/ix.html

Ali
Aug 09 2022
parent pascal111 <judas.the.messiah.111 gmail.com> writes:
On Tuesday, 9 August 2022 at 18:10:25 UTC, Ali Çehreli wrote:

 On 8/2/22 09:40, pascal111 wrote:


 [...]


 in C++, so

 [...]


 Lambdas are a common feature of many programming languages. C++ 
 got lambdas in their C++11 release, many years after D and many 
 other languages had them. (It is not common for the C++ 
 community to give credit. Most of their features are presented 
 as C++ inventions when they are not. For example, almost the 
 entirety of the C++11 features already existed in D (and other 
 languages before D).)

 [...]


Thanks!
Aug 09 2022