August 01, 2022

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?!!"

August 01, 2022

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.

August 01, 2022

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.

August 01, 2022

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:

>

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.

August 01, 2022

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:

>

[...]

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.

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.

August 01, 2022

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.

August 01, 2022

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. :)

August 02, 2022

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

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

or even longer:

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:

auto is_even = [](int i){ return i%2 == 0; };
auto result = std::find(..., ..., is_even);
August 02, 2022

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.

August 09, 2022
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