3 ms·

Functional Programming is just composing a program with pure functions, nothing else. Immutability and closures are required for that, because mutability may b

Functional Programming is just composing a program with pure functions, nothing else. Immutability and closures are required for that, because mutability may break homoiconicity (which is required for purity), and lack of closures means you can't pass state around. Higher-kinded types are very useful for helping with lots of functional abstractions, but they are a type system feature and have nothing to do with FP. If someone claims that, this person doesn't understand FP or type systems. OCaml and Standard ML are two examples of languages without higher kinded types but are just as good as Haskell for FP. (Although they have a powerful module system to compensate for that).

the_af 12y ago
> because mutability may break homoiconicity (which is required for purity) Are you sure you meant that? My (admittedly weak) understanding of homoiconicity is that it's unrelated to either purity or (im)mutability. Isn't homoiconicity related to the program text and its AST? Aren't there languages such as Haskell which encourage pure functions but are not homoiconic? I'm pretty sure you meant something else...
- abathologist 12y ago
  I bet "referentiality" was meant. It would make sense as a replacement for "homoiconicity".
  - abathologist 12y ago
    I bet "referential transparency" was meant. It would make sense as a replacement for "referentiality". oops :(
  - Denommus 12y ago
    Yes, that's what I meant, I don't know why I got it wrong.
abathologist 12y ago
> they are a type system feature and have nothing to do with FP I suggested in a sibling reply that the use of type-theoretic notions in FP is a natural out growth of the initial motives of the FP paradigm. While I wouldn't think that FP languages must incorporate type-theoretic notions, it does seem to me fitting that many would, since type systems have been involved with the functional understanding of computation since quite early on. Do think that line of reasoning make sense?
dragonwriter 12y ago
Mutability directly breaks purity whether or not it breaks homoiconicity. This should be obvious because on of the best known and oldest FP language families is both homoiconic and impure due to mutation (the Lisp family.) So homoiconicity is a non-sequitur.

the_af 12y ago

> because mutability may break homoiconicity (which is required for purity) Are you sure you meant that? My (admittedly weak) understanding of homoiconicity is that it's unrelated to either purity or (im)mutability. Isn't homoiconicity related to the program text and its AST? Aren't there languages such as Haskell which encourage pure functions but are not homoiconic? I'm pretty sure you meant something else...

abathologist 12y ago
I bet "referentiality" was meant. It would make sense as a replacement for "homoiconicity".
- abathologist 12y ago
  I bet "referential transparency" was meant. It would make sense as a replacement for "referentiality". oops :(
- Denommus 12y ago
  Yes, that's what I meant, I don't know why I got it wrong.

abathologist 12y ago

> they are a type system feature and have nothing to do with FP I suggested in a sibling reply that the use of type-theoretic notions in FP is a natural out growth of the initial motives of the FP paradigm. While I wouldn't think that FP languages must incorporate type-theoretic notions, it does seem to me fitting that many would, since type systems have been involved with the functional understanding of computation since quite early on. Do think that line of reasoning make sense?

dragonwriter 12y ago

Mutability directly breaks purity whether or not it breaks homoiconicity. This should be obvious because on of the best known and oldest FP language families is both homoiconic and impure due to mutation (the Lisp family.) So homoiconicity is a non-sequitur.