[mrkeen]

Here's a good enough definition: "The same input yields the same output".

> "functional programming is a programming paradigm where programs are constructed by applying and composing functions"

This is only seems like a useless truism if you take 'function' to mean 'method' or 'procedure'. If you nail down 'function' to sameinput->sameoutput then it starts to make more sense.

[ninetyninenine]

No. You missed it the meaning. The paradigm is referring to the fact that the ENTIRE program must be constructed this way.

So let's say you have this in your code:

   x = 1
   b = x + 2
   x = b + x

You have composed three procedures here in order. This is illegal. You must ONLY construct the programs via composing functions there can be no other way.

[hollerith]

Not so fast. This next is legal Haskell:

  let x = 1
      b = x + 2
      x = b + x
  in <do something with b and x>

The third line creates a second binding of x which shadows the first binding, and shadowing is considered by most people to be within the functional paradigm. What is not considered functional by most people is assigning a variable in a loop although even here you can do it in Haskell. Specifically, you can call readIORef and writeIORef every loop iteration, but last time I tried, that was about 1000 times less efficient than in an imperative language.

[ninetyninenine]

The intent of my syntax is to show mutation and procedures not variable shadowing and let in.

[mrkeen]

I don't think I missed anything. You presented non-functional code as an example of code which isn't functional. There's no contradiction.

And good riddance, too! I'm so sick of seeing this anti-pattern at $DAYJOB: First, create a thing which isn't what you called it (e.g. 'result'), and then mutate it in place until it is what you called it.