Operations encompass both functions and procedures.

A function is time-invariant.

Procedures are a series of operations over time, and may include flow-control mechanisms such as return.

I wrote 'higher order operations' rather than 'higher order functions' for a reason.

It's true that lambda calculus is generally functional, but it's not fundamentally required to be so -- consider web.mit.edu/6.827/www/old/lectures... for example.

(But that's irrelevant, since your reference to lambda calculus came from confusing higher order operation with higher order function)

Certainly you can write procedures that implement functions in javascript -- I am not sure why this is relevant.

Operations encompass both functions and procedures.
A function is time-invariant.
I wrote 'higher order operations' rather than 'higher order functions' for a reason.

Regarding this, there seems to have been a miss on my part. When I was speaking of the functions map and reduce I didn't mean they had to be time-invariant (by time-invariant I assume you mean it follows the mathematical definition of a function, also known as pure or referentially transparent). The word "function" is used so widely in the programming world to just refer to what you call operation. When speaking of time-invariant functions the most common terminology is "pure function" (from what I have seen).

It's true that lambda calculus is generally functional, but it's not fundamentally required to be so -- consider web.mit.edu/6.827/www/old/lectures... for example.

From what I understand it is a requirement. The lecture you linked was very interesting. I didn't understand all of it. But they use what they call I-structures and M-structures to isolate the side effects and keeping them pure. So in a similar manner to Haskell's IO Monad, but it's not a monad. Either way, it's not the kind of "do IO anywhere" that imperative languages have. Apparently this method should let them model languages with implicit parallelization and they used it to create the language pH (Parallel Haskell), not sure about the state of that language today since this is from the late '90s. But they also lose some benefits of regular lambda calculus when expanding it like that.

I feel like this discussion has reached a point where neither of us is making any progress in convincing the other, so I'm leaving this as my last comment and will not reply any further. Below I linked some more resources on lambda calculus and side effects that I read to get a better understanding of the lecture slides. It was very fun and interesting to read. So thanks for that.

I saw that the lecture you linked was the first result on Google for "lambda calculus side effects". It's not very comprehensive and was hard to understand. Here's a paper that covers some more basic parts first. cs.tufts.edu/~nr/cs257/archive/nea...

Here's the research paper which I believe the lecture is based off. I only read about half of the paper, but it helped me understand the lecture slides. reader.elsevier.com/reader/sd/pii/...

Both papers are by the same researchers and it was pretty much the only resources I found on side effects in lambda calculus.

## re: Why I love learning functional programming VIEW POST

TOP OF THREAD FULL DISCUSSIONOperations encompass both functions and procedures.

A function is time-invariant.

Procedures are a series of operations over time, and may include flow-control mechanisms such as return.

I wrote 'higher order operations' rather than 'higher order functions' for a reason.

It's true that lambda calculus is generally functional, but it's not fundamentally required to be so -- consider web.mit.edu/6.827/www/old/lectures... for example.

(But that's irrelevant, since your reference to lambda calculus came from confusing higher order operation with higher order function)

Certainly you can write procedures that implement functions in javascript -- I am not sure why this is relevant.

Regarding this, there seems to have been a miss on my part. When I was speaking of the functions

`map`

and`reduce`

I didn't mean they had to be time-invariant (by time-invariant I assume you mean it follows the mathematical definition of a function, also known as pure or referentially transparent). The word "function" is used so widely in the programming world to just refer to what you call operation. When speaking of time-invariant functions the most common terminology is "pure function" (from what I have seen).From what I understand it is a requirement. The lecture you linked was very interesting. I didn't understand all of it. But they use what they call I-structures and M-structures to isolate the side effects and keeping them pure. So in a similar manner to Haskell's IO Monad, but it's not a monad. Either way, it's not the kind of "do IO anywhere" that imperative languages have. Apparently this method should let them model languages with implicit parallelization and they used it to create the language

pH(Parallel Haskell), not sure about the state of that language today since this is from the late '90s. But they also lose some benefits of regular lambda calculus when expanding it like that.I feel like this discussion has reached a point where neither of us is making any progress in convincing the other, so I'm leaving this as my last comment and will not reply any further. Below I linked some more resources on lambda calculus and side effects that I read to get a better understanding of the lecture slides. It was very fun and interesting to read. So thanks for that.

I saw that the lecture you linked was the first result on Google for "lambda calculus side effects". It's not very comprehensive and was hard to understand. Here's a paper that covers some more basic parts first.

cs.tufts.edu/~nr/cs257/archive/nea...

Here's the research paper which I believe the lecture is based off. I only read about half of the paper, but it helped me understand the lecture slides.

reader.elsevier.com/reader/sd/pii/...

Both papers are by the same researchers and it was pretty much the only resources I found on side effects in lambda calculus.

That's fine.

I suggest that you go back over the thread and look at the places where your positions have been self-inconsistent, as it may be educational.

Best of luck.