Here’s the formalisation you’re looking for:

Both objects and closures are modelled by a particular pattern involving existential types.

Here’s the definition of closures:

type Fn a b = exists e. {
  env : e,
  code : (e, a) -> b
}

apply : (Fn a b, a) -> b
apply(f, x) = f.code(f.env, x)

And here’s a “mutable counter” object that’s often used in OO examples:

type Counter = exists s. {
  state : s,
  next : s -> (),
  read : s -> int
}

new : Counter
new = {
  state = Ref.new(0),
  next = Ref.modify (+ 1), 
  read = Ref.get
}

next : Counter -> ()
next c = c.next c.state

read : Counter -> int
read c = c.read c.state

The pattern has a generic name: the greatest fixed point of a functor (I will expand on this by request). Types that can be represented by the greatest fixed point of a functor are called conductive types, or codatatypes.

Objects and closures are both codatatypes.

I can’t emphasize how much this changed how the way i program

I was writing the first version of my language (peacock) in functional style JavaScript & then at some point i realized all these closures were just messy ad hoc immutable classes.

Over a few iterations i landed in OO ruby & i never thought id say this years ago but OO is really really beautiful, over time i started to introduce more mutation when it called for it & i found the end result was significantly simpler & more maintainable code.

Moral of the story is dogma like “OO is bad”, “mutation is bad” is not only wrong, but such a limiting & IMO boring way to view the world.

Let’s make this a lot simpler (not for anyone who’s already posted in the thread because I can tell that y’all get it, but for anyone else who’s lurking):

Closures are functions that carry some of their own data with them. Object instances are data that carry some of their own functions with them.

For example, imagine you had a speak-some-text() function that you wanted to carry a text and keep track of where in the text you are so you can speak the next part and then place a new bookmark. A closure can do that.

Or, if you had a book object that had members such as text and position and a method speak-at-current-position(). An object instance can do that.

So as you see you can do kind of the same thing.

What’s frustrated me in the past with object systems is when all I needed was a normal first-class function, I didn’t need to carry any state or data, but I had to make an object (with no members and a single method) anyway (because this was when Java didn’t have first class functions, maybe they still don’t, it was 15 years ago, IDC), and in order to make the object I had to make a class, it was a hole schlep for what’s trivial and like two characters in a language with first class functions like shell scripting, JS, or lisp.

What’s frustrated me in the past with SICP-style “closures are objects”, the kind of overwrought closing over a symbol-message dispatch (making kind of a Smalltalk or Obj-C style implementation), is that there’s no inheritance; you can work around that easily enough with composition or adapters but sometimes you just want a beautiful concise object system. ♥

Overall I prefer closures and use them all the time and I very rarely want an object system. When I do it’s because I’m trying to solve a Simula type problem like a GUI or a set of actors such as monsters in a video game.

Python is not a great language for demonstrating this though because you have to use nonlocal to assign to any closure variables. Going further, objects, closures, and just plain old passing a lot of arguments are all roads to the same end.

I gave a talk about this symmetry at BOB 2020 in Berlin. I’m linking the org-mode slides here in case people are interested. They discuss the symmetry in practice, and also some theoretical / more advanced elements.

Something that people often don’t recognize is that, while the Expression Problem suggests that OO programs are make it easier to add new data cases, while FP make it easier to add new operations (without modifying existing code), in practice in my experience readability is also affected: it’s easier to read code where all the logic is in the same place, so FP code makes operations easier to read and OO code makes “data cases” easier to read. I think this has potential consequence for code visualization tools.

This is very easy to show in Common Lisp:

(defun make-person-object (&key (name) (age))
  (let ((person-age age)
        (person-name name))
    (lambda (message &rest args)
      (cond
        ((eq message :print)
         (format t "Person ~s aged ~a~%" person-name person-age))

        ((eq message :set-age)
         (setf person-age (car args)))

        ((eq message :get-age)
         person-age)

        (t (error "Person does not handle ~a message" message))))))

(defparameter *bob (make-person-object :name "Bob" :age 42))
(funcall *bob* :print)
(funcall *bob* :set-age 43)
(funcall *bob* :print)
(format t "Bob is: ~a~%" (funcall *bob* :get-age))
;; And you can do interesting things like:
(disassemble *bob*)

Using closures to implement objects that respond to messages is also famously done in SICP. If you take this to its limit, you can implement a full class-based object system (even with a meta object protocol, if you like) using only closures.