[tel]

This kind of becomes a name game, what is truly "FP". For many, FP is meaningfully defined as a focus on functions and it's silly to try to define that away.

There is something, "ML-alike FP" or, even, "Haskell-alike FP" which I might call "pure FP" which is what you say. This is less difficult to see as being centralized on purity more than "FP" at large. Presumably, you could have "pure" OO, classes and all, by eschewing effects just the same.

I have at least one bet in the pot that you cannot, though. I think the true beating heart of "pure FP"/"Haskell-alike FP" is the centricity of composition as a guiding design of language. This comes directly from some of the category theoretic heritage of the core languages here. Once you're here, the primality of functions themselves is hard to escape from. You can go a ways without HOFs, but the lack of richness of composition which you're stuck with is very painful. BiCCCs are a very sweet spot.

[nightski]

But a function isn't really a function unless it is referentially transparent. Having HoF, composability, etc.. is all a direct result of referential transparency.

Sure we can simulate these concepts in imperative languages, but the broken abstractions break down rather quickly since the laws are ignored.

[tel]

It's just a function in a different, less observable category. That's not the worst thing. And, of course, I'd like to argue for "pure FP" too.

Really, I just want to sidestep the argument that is appearing all over this post: that "FP" is also this, and this, and this.

Sure. FP is terrifically poorly defined. The definition used in the article is rather more specific than what most people would say. But it has merits and should be discussed. Let's just not stumble over naming difficulties to do so.