So you kinda just don't need for loops anymore and they're inherently imperative because you need to setup some sort of condition to say keep performing this sequence of actions (which is the main idea behind imperative programming) until this condition is no longer satisfied.
Loops are not expressions.
(Where I assume that you are talking about for-loops and the like.)
https://mitpress.mit.edu/sicp/full-text/sicp/book/node15.htm...
The advantage of using recursive definitions for loops is that it avoids modifying places in favor of returning values. Rich Hickey gives a good talk on the subject in The Value of Values:
For loops dont return a value, whereas forM and even forM_ both return values. They are normal functions rather than just control structures.
At least, what makes one language imperative vs functional?
I always thought functional languages were about describing what things should do whereas imperative languages were about telling the computer what to do. I suppose in that sense loops are not really functional because they are not very descriptive, but I was wondering if there was more to it than that.
Let's start with a simple function that counts down from five in Javascript:
var countDownFromFive = function() {
console.log(5);
console.log(4);
console.log(3);
console.log(2);
console.log(1);
console.log(0);
}
var countDownFrom = function(num) {
console.log( num );
if (num >= 0) {
countDownFrom(num - 1);
}
}
var countDownFromFive = function() {
countDownFrom(5);
}
Indeed, until we've invented them, we don't even have the necessary concepts of a stack with function frames. So, let's look at our problem again.
Let's pretend we're in a very limited assembly language, with just registers:
LOAD registerA 5
PRINT registerA
LOAD registerA 4
PRINT registerA
LOAD registerA 3
PRINT registerA
LOAD registerA 2
PRINT registerA
LOAD registerA 1
PRINT registerA
LOAD registerA 0
PRINT registerA
start:
LOAD registerA 5
doPrint:
PRINT registerA
DECREMENT registerA
JUMP_IF_NOT_NEGATIVE registerA doPrint
finish:
HALT
~
The thing we see, though, is that the difference in implementation comes from basically whether or not you can compose functions: if you can, you use the functional approach. If you can't, you refactor the problem to have an explicit accumulator (your loop variable).
Loops can be considered an inherently imperative idea because you have this changing context wrapping the function being invoked (a mutating accumulator, if you will)--in the functional world, you merely wrap another function which itself creates a new context with the desired mutation, and that function in turn calls another function setting up its own context and so on and so forth. It's somewhat handier to prove correctness and behavior of these recursive functions compared with their mutating accumulator imperative solutions; at the same time, they are slower without compiler support.
I guess I never thought about it that way but the logic in the loops could be considered their own functions, except they actually can reference and alter variables outside the loop which is kind of against the ideas of functional programming.
Awesome! Thanks again
One last thing: the core idea of functional programming is mapping state to state, the same way a transform matrix maps a vector to another vector. So, to accomplish something, you string together functions to map you from the state you have to an ultimate state that you want.
For something like calculating the average of a set of numbers, this would be:
[ set of numbers ] -> function maps from the "set of numbers space" to the "sum of all numbers in a set space" --> function that maps from the "number space" to the "number space scaled by a value (here being the number of original numbers in the set)" --> your final mean
In most languages, the usefulness of for loops is almost entirely contingent upon either mutability (in the form of some accumulating variable and/or explicit alteration of program state) or on side effects like I/O routines. Partly, these things are often only necessary because the language itself doesn't handle recursion well; why use a for loop to generate a factorial, for example, when I can simply call the function again?
However, you can get something an awful lot like a traditional for loop, while still staying relatively functional pure: in Racket and Heresy, for loops are actually just some familiar syntax sugar layered on top of what's actually a recursive function. They actually become an abstraction over a very common pattern in Lisp languages: the let loop.
In Racket, often times I still need to accumulate some value over successive computations, but I don't necessarily need to build a whole named function to do it. In those scenarios I can make a let loop, which looks like this:
(let foo ([var 0]
[l '()])
(if (> var 10)
l
(foo (+ 1 var) (cons var l))))
(for/list ([x (in-range 10)])
x)
(for (x in (range 1 to 10) with '())
(carry (join x cry)))
There are of course complications with this; the functional for loop is great in dynamically typed languages but it can be tricky to correctly type-check, which is why in Haskell it's a monad-y thing, and in Typed Racket there's a number of bugs still being worked out for handling the for loops.
Still, the two aren't necessarily mortal enemies, or explicitly imperative or functional, it just takes some thinking about what you wish to do.