I think the problem is that you're misunderstanding what they mean by the use of an intermediate value (or they're misrepresenting it, I haven't read the link). Consider that a variable in a functional language is the definition
of something, and that definition cannot change. It's perfectly acceptable to use names for values/formulas in functional programming, as long as they don't change.
function calculate(a,b,c) {
// here we define an name to (a+b) so that we can use it later
// there's nothing wrong with this "functionally", since we don't
// change it's definition later
d = a + b;
return c * d;
}
On the other hand, the following would not be ok, functionally
function sum(listofvalues) {
sum = 0;
foreach value in listofvalues
// this is bad, since we're re-defining "sum"
sum += value;
return sum
}
For something closer to what you had in your code... consider you have a function call map that takes a list of things and a function to apply to a thing and returns a new list of things. It's perfectly acceptable to say:
function add_value(amount) {
amount_to_incr = amount * 2;
return function(amount, value) {
// here we're using that "amount" value provided to us
// the function returned will always return the same value for the same
// input... its "referentially transparent"
// and it uses the "intermediate" value of amount_to_incr... however, since
// that value doesn't change, it's fine
return amount_to_incr + value;
}
}
map [1,2,3] add_value(2) ;// -> [3,4,5]
a
in your function. Its bound up in a closure – Wimberlylet
in Haskell. – Equalitarian