3 ms·

I do not think functional programming is about mutable state at all. It's about functions being first class values, nothing more. Lisp and Scheme are examples

I do not think functional programming is about mutable state at all. It's about functions being first class values, nothing more. Lisp and Scheme are examples of functional languages that do not restrict mutability. The term for what you are talking about is pure functional programming!

kazinator 3y ago
I don't think this is correct. Programming languages with support for functional programming are not always pure functional languages. However, functional programming per se is always pure by definition; if you're mutating anything, it's not functional. (You can have "quasi functional" if you mutate only local variables, such that the black box view of your functions appears pure. Nobody knows whether the map function in (map f list) internally contains a loop or tail recursion.) Languages which support functional programming and other paradigms are not called functional; it is not correct to call Common Lisp and Scheme functional. Not only do these have mutation, they have sequencing via strict evaluation: doing one thing that has a side effect, followed by another. Side effects like I/O and mutation are easily obtained and ordered, just like in Fortran or Java.
- chlorion 3y ago
  Pure functional programming is always about purity, functional programming is about first class functions. Pure functional programming is a subset of functional programming, not the other way around. I'm not really sure where you are getting your information from but everything that I have read disagrees with this idea that functional programming is about purity. https://en.wikipedia.org/wiki/Functional_programming https://en.wikipedia.org/wiki/Functional_programming I think in recent times the term functional programming has been overloaded to mean what you describe, and many people use it that way, but I don't think it should be used that way. Maybe we should just say "non pure functional" or "pure functional" so it's always clear what we are talking about!
  - deleted 3y ago
    [deleted]
  - kazinator 3y ago
    Many mainstream programming languages implement procedures and functions with the same syntax, and call procedures functions. Procedures can take arguments and return a value, like functions, but also have side effects. Nobody asked for this terminology mixup; it just happened in the reference manuals of programming languages. Lisp calls procedures functions; so does C. Programming with procedures isn't functional programming; it is procedural programming. This is true even when the procedures are first-class procedures, and are used in declarative patterns like mapping, reducing and so on. There is no word which refers to programming with first-class procedures in a declarative style. It is different from "Fortran-like procedural", and is rooted in OOP. First class procedures are objects; and in fact in many languages you can take a solution based on first class procedures and replace those procedures with objects. Mutated lexical variables become member variables (or slots) and so on. The rhetoric in this area conflates two meanings of "pure" and "purely", causing equivocation. - "pure X" as in "consisting of nothing but X" and "purely X" meaning "solely X" - "pure" as in having no side effects: a pure expression can be replaced by its value without a change in meaning. A "not purely functional language" uses "purely" in the former sense. The language emphasizes functional features, but has procedural features also. It doesn't refer to a language which emphasizes declarative programming patterns around first-class procedures, though such a language can fit the description. A "not purely functional program" likewise: it emphasizes functional programming but has procedural bits in there. It doesn't refer to the program being composed entirely of the declarative use of higher order procedures, like mapping over collections while doing I/O or mutation and such. If we take the value of a variable and then filter it through functional stages, only to then assign the transformed value into the same variable by assignment, that is an example of "not purely functional". The data transformation is functional; the assignment isn't.

kazinator 3y ago

I don't think this is correct. Programming languages with support for functional programming are not always pure functional languages. However, functional programming per se is always pure by definition; if you're mutating anything, it's not functional. (You can have "quasi functional" if you mutate only local variables, such that the black box view of your functions appears pure. Nobody knows whether the map function in (map f list) internally contains a loop or tail recursion.) Languages which support functional programming and other paradigms are not called functional; it is not correct to call Common Lisp and Scheme functional. Not only do these have mutation, they have sequencing via strict evaluation: doing one thing that has a side effect, followed by another. Side effects like I/O and mutation are easily obtained and ordered, just like in Fortran or Java.

chlorion 3y ago
Pure functional programming is always about purity, functional programming is about first class functions. Pure functional programming is a subset of functional programming, not the other way around. I'm not really sure where you are getting your information from but everything that I have read disagrees with this idea that functional programming is about purity. https://en.wikipedia.org/wiki/Functional_programming https://en.wikipedia.org/wiki/Functional_programming I think in recent times the term functional programming has been overloaded to mean what you describe, and many people use it that way, but I don't think it should be used that way. Maybe we should just say "non pure functional" or "pure functional" so it's always clear what we are talking about!
- deleted 3y ago
  [deleted]
- kazinator 3y ago
  Many mainstream programming languages implement procedures and functions with the same syntax, and call procedures functions. Procedures can take arguments and return a value, like functions, but also have side effects. Nobody asked for this terminology mixup; it just happened in the reference manuals of programming languages. Lisp calls procedures functions; so does C. Programming with procedures isn't functional programming; it is procedural programming. This is true even when the procedures are first-class procedures, and are used in declarative patterns like mapping, reducing and so on. There is no word which refers to programming with first-class procedures in a declarative style. It is different from "Fortran-like procedural", and is rooted in OOP. First class procedures are objects; and in fact in many languages you can take a solution based on first class procedures and replace those procedures with objects. Mutated lexical variables become member variables (or slots) and so on. The rhetoric in this area conflates two meanings of "pure" and "purely", causing equivocation. - "pure X" as in "consisting of nothing but X" and "purely X" meaning "solely X" - "pure" as in having no side effects: a pure expression can be replaced by its value without a change in meaning. A "not purely functional language" uses "purely" in the former sense. The language emphasizes functional features, but has procedural features also. It doesn't refer to a language which emphasizes declarative programming patterns around first-class procedures, though such a language can fit the description. A "not purely functional program" likewise: it emphasizes functional programming but has procedural bits in there. It doesn't refer to the program being composed entirely of the declarative use of higher order procedures, like mapping over collections while doing I/O or mutation and such. If we take the value of a variable and then filter it through functional stages, only to then assign the transformed value into the same variable by assignment, that is an example of "not purely functional". The data transformation is functional; the assignment isn't.