That does not mean that the JavaScript community knew what they're talking about. ;-)
Additionally to my personal and probably debatable perception that referring to a certain lambda notation as an "arrow function" because an arrow is involved is like referring to a C pointer as an "asterisk variable" because an asterisk is involved, I would say const whatever = num => num * 2is a lambda function because the return value is used for output, not just discarded...?
The technical distinctions are tricky, so I really can't say for sure. We might need to dig up Alonzo Church to settle the matter. :)
I do think that arrow functions are not always lambda expressions, and lambda expressions are not always arrow functions. So arrow != labmda.
Here are a couple interesting examples that show some of the gray areas though:
const whatever = num => num * 2
anonymous: true (edit: it's an anonymous function set to a variable, see comment below)
arrow: true
lambda: ...I don't think so
It's named, so what is the distinction between this syntax and a "normal" function declaration? Both can be passed around as first class citizens so what is it about the arrow function that would make it a lambda, but not the function declaration?
var myArrays = [[1,2,3], [4,5,6]]
myArrays.forEach(array => array.splice(0,1))
In this case, the return value is discarded but I think that arrow function still qualifies as a lambda expression because it's anonymous and because of how it's used. I used "splice" in this example because it does mutate the array, but even if it were a "slice" instead I think it would have to be considered a lambda...though, not a useful one!
Well...yes! Good call. I'll revise my comment above.
I know there is a difference between the function declaration and function expressions, and in the example I gave it's definitely not using the function declaration.
As for what technically counts as being a lambda expression or not...I really don't know.
That does not mean that the JavaScript community knew what they're talking about. ;-)
Additionally to my personal and probably debatable perception that referring to a certain lambda notation as an "arrow function" because an arrow is involved is like referring to a C pointer as an "asterisk variable" because an asterisk is involved, I would say
const whatever = num => num * 2is a lambda function because the return value is used for output, not just discarded...?The technical distinctions are tricky, so I really can't say for sure. We might need to dig up Alonzo Church to settle the matter. :)
I do think that arrow functions are not always lambda expressions, and lambda expressions are not always arrow functions. So arrow != labmda.
Here are a couple interesting examples that show some of the gray areas though:
const whatever = num => num * 2anonymous: true (edit: it's an anonymous function set to a variable, see comment below)
arrow: true
lambda: ...I don't think so
It's named, so what is the distinction between this syntax and a "normal" function declaration? Both can be passed around as first class citizens so what is it about the arrow function that would make it a lambda, but not the function declaration?
var myArrays = [[1,2,3], [4,5,6]]myArrays.forEach(array => array.splice(0,1))
anonymous: true
arrow: true
lambda: ...I think yes?
In this case, the return value is discarded but I think that arrow function still qualifies as a lambda expression because it's anonymous and because of how it's used. I used "splice" in this example because it does mutate the array, but even if it were a "slice" instead I think it would have to be considered a lambda...though, not a useful one!
fetch('https://dev.to').then(function(response) { console.log(response); })anonymous: true
arrow: false
lambda: ...I think yes?
This uses an old skool anonymous function, it's not an arrow function but I believe it's still a lambda expression.
Edit: typo, adding non-arrow function
Apologies my question but in your first example. Isn't it just a anonymous function that has been assigned to a variable?
Well...yes! Good call. I'll revise my comment above.
I know there is a difference between the function declaration and function expressions, and in the example I gave it's definitely not using the function declaration.
As for what technically counts as being a lambda expression or not...I really don't know.
Quite hard to tell it seems. Although, this is a good summary