In that case it is not pure functional programming because you are colocating state with logic.
Functions in that file can mutate the state within that file; this means that it's only functionally transparent within that file
but not from the outside.
If you need to store state inside of that file, then it means that you are using it to affect the behaviour of functions which are exposed to the outside...
Also, this approach would be sub-par because you would be constrained to singleton modules.
What you described sounds like a Haskell programming anti-pattern.
It sounds like a feature which was hacked on top to allow Haskell to emulate OOP languages without actually doing OOP.
Also, lazy evaluation is a separate topic. OOP languages also support lazy evaluation.
No. OOP isn't "colocating", it's "encapsulating". FP does it differently, but whatever the paradigm, programmer ergonomics suggest that it would be unsurprising to see definitions of (say) data and functions close together.
What source code files you happen to put declarations and definitions in has nothing to do with functional purity.
Think of it this way:
An array append function which adds an element to the input array is not purely functional.
An array append function which returns a new array with the new element appended is purely functional.
The same function applied to the same input will always return the same value, and won't cause that to break for any other functions.
Of course, this makes things such as IO tricky and yo ideally want to minimize and isolate the places where this happens on a lower level.
Haskell solves this with monads, which we have seen is a big hurdle for many developers. I personally think Idris's effect system[0] is a lot easier to deal with, but would be curious to see other approaches.
>> An array append function which returns a new array with the new element appended is purely functional.
>> The same function applied to the same input will always return the same value, and won't cause that to break for any other functions.
I think this is the essence of why a lot of developers use functional programming but I think that in this case functional programming is not a solution to the real problem which is an architectural problem.
If the relationship between different components in your system is clear and hierarchichal, you should never need to keep the same data/array in two places. You can come up with simple abstractions so that you only ever have one source of truth for each kind of state. That means you can read it anywhere but only write to it in one place.
I think that functional programming cannot solve this root problem, you will just end up with different symptoms. For example, instead of mutating a single array in unexpected ways, in FP, if you have multiple sources of truth, you might end up with multiple conflicting copies of the same data. Same root problem and it's just as difficult to identify and debug as in OOP, just different symptom.
If you need to store state inside of that file, then it means that you are using it to affect the behaviour of functions which are exposed to the outside... Also, this approach would be sub-par because you would be constrained to singleton modules.
What you described sounds like a Haskell programming anti-pattern. It sounds like a feature which was hacked on top to allow Haskell to emulate OOP languages without actually doing OOP.
Also, lazy evaluation is a separate topic. OOP languages also support lazy evaluation.