[galaxyLogic]

Excellent exposition of the current landscape and of the notion that there is no single definition of FP.

I'd like to add that type-systems are not a defining feature of functional programming because you can have type-systems in what are considered "non functional" languages as well.

Immutability it jives with functional but is really an orthogonal feature as well.

So what is left? I would say is the ability to create closures because that clearly MAKES IT EASY TO CREATE FUNCTIONS without having to separately type the separate source-code of every individual function. Closures make that easy. Closures make it easy to "calculate with functions" because it becomes so easy to create new functions.

[jerf]

Yeah, I kinda think the Haskell branch ought to have its own term, because of the number of things that are involved that don't relate to "functions" per se, but it's not my call. "Pure functional" sort of works, but I would mean something more like "Pure and functional", that is, two separate adjectives, not one where "pure" is modifying "functional". A pure, non-functional language is certainly possible. "Pure imperative" is a bit hard to conceive (Rust probably as close as you can get), but an SQL database set to a high transaction isolation level can be seen as a pure non-functional language. (And I say "can" because it can also be argued against. But it's at least debatable.)

[dragonwriter]

> Yeah, I kinda think the Haskell branch ought to have its own term, because of the number of things that are involved that don't relate to "functions" per se, but it's not my call. "Pure functional" sort of works, but I would mean something more like "Pure and functional", that is, two separate adjectives, not one where "pure" is modifying "functional".

“Pure functional” programming is functional programming wherein the functions are pure functions, that is: (1) the result of the function is completely determined by the identity of the function and its arguments, and not any other external state, and (2) the function produces no side effects that would impact calls to the same or other functions. (On a language level, only the first is really necessary, because if everything is composed of functions and all functions results are independent of external state, any side effects would necessarily not be observable within the language; but functional purity can be discussed with regard to constructs within a language where purity is not required at the language level.)

> A pure, non-functional language is certainly possible.

You can have referential transparency in a language whose central structure is determined by a paradigm other than the functional (e.g., referential transparency is just as much a key feature in the logic programming paradigm as the functional paradigm, and pure logic programming is already used to describe logic programming with strict referential transparency in the same way pure functional programming refers to functional programming where with strict referential transparency.)

> "Pure imperative" is a bit hard to conceive (Rust probably as close as you can get),

Rust is basically an ML-family functional language that moved off in a different direction than the one toward purity; it's closer to impure functional than pure anything.