They are definitely still "functions", barring the fact that Java doesn't have first-class functions and SAMs are the closest thing. C# does have first-class functions, and it is even more liberal in its closure rules. (Java can only close over `final` variables, which are immutable variable bindings. C# doesn't even have immutable variable bindings, only member bindings.)
Also, they can still be "pure functions". Purity is a relation of side effects, not of mechanisms. (Even then, it's a somewhat loose definition -- is allocating memory a side effect?) If you don't allow closures to escape their declared scope, you can handle closed values as extra parameters. So closures don't mean you suddenly can't write pure functions, it means that some input to the function is pre-determined. In other words, closures have the same implications to purity as parameter binding -- absolutely none.
You are kind-of making my point. It's clearer to use "function" fore pure, mathematical functions, and otherwise "procedure"/"object"/"proxy"/"closure" whatever. Even if some popular languages misuse the term "function".
> Even then, it's a somewhat loose definition -- is allocating memory a side effect?
This is leading nowhere. Is loading a value into a register a side effect? If you care.
I mean, if you're only point is that programmers use the term "function" to mean something other than a pure mathematical mapping from one set to another... You won't get any arguments from me.
Also, they can still be "pure functions". Purity is a relation of side effects, not of mechanisms. (Even then, it's a somewhat loose definition -- is allocating memory a side effect?) If you don't allow closures to escape their declared scope, you can handle closed values as extra parameters. So closures don't mean you suddenly can't write pure functions, it means that some input to the function is pre-determined. In other words, closures have the same implications to purity as parameter binding -- absolutely none.