[Jweb_Guru]

Purity seems to be totally orthogonal to this question, to me. I'm referring to the ability to return thunks from within called functions, such that the data are totally encapsulated in the closure (are not passed in explicitly and cannot be retrieved manually). That seems to be coupling data and behavior to me, since you can't run the function without the data it was coupled with at construction time. Whether that's fundamental or not is, of course, a subjective question, but I have a hard time thinking of a language that bills itself as functional that doesn't provide that capability natively (Rust and C++ make it difficult, but neither really bill themselves as functional).

[wyager]

> Purity seems to be totally orthogonal to this question, to me.

Ah, well there's the confusion. A language with semantically impure closures emphatically does not reproduce the semantics of the lambda calculus unless you restrict yourself to only pure, immutable variables. But if you reproduce the lambda calculus, there's no need for closures as we know them. It's just an implementation that happens to work well. You could supercompile the lambda-abstraction at the application site and avoid having a closure. It's just not a good idea.

But I agree, in a language with mutable variable capture, you can reproduce the semantics of OOP by providing a bundle of functions closed over mutable references to the "object" data.

> a language that bills itself as functional that doesn't provide that capability natively

I'm not sure exactly what capability you're referring to. Could you clarify a little bit?

[Jweb_Guru]

I'm referring to "information hiding" by providing a function that uses currying in order to close over data that cannot be accessed from the caller. For example:

    (* foo.ml *)
    let bar =
      let foo = lambda x . lambda y .
        if y == 0 then { getFoo : lambda z . 0 }
        else { getFoo : lambda z . (x * z - x + z) / y }
        end
      in foo 3

    (* bar.ml *)

    include foo.ml

    let y = bar 5
    bar.getFoo(4)

It sure seems to me that bar is hiding the 3 from bar.ml (and there are much more complicated examples where foo.ml really can't get at the captured type, for instance), and at the same time it's capturing the value of 5. The function getFoo on bar is bound to it (the record type can desugar to more curried lambdas, if necessary, it's just tedious and this illustrates my point better).

None of this seems to have anything to do with mutation, to me, though it certainly seems to have both information hiding and binding logic and data. The fact that it can be compiled not to use closures (using whole-program compilation) is immaterial; the same is true for the same program specified with objects in mutable languages (SML has both mutation and closures, and MLton does exactly that).