Is there a relationship between calling a function and instantiating an object in pure functional languages?

Question

Imagine a simple (made up) language where functions look like:

function f(a, b) = c + 42
    where c = a * b

(Say it's a subset of Lisp that includes 'defun' and 'let'.)

Also imagine that it includes immutable objects that look like:

struct s(a, b, c = a * b)

Again analogizing to Lisp (this time a superset), say a struct definition like that would generate functions for:

make-s(a, b)
s-a(s)
s-b(s)
s-c(s)

Now, given the simple set up, it seems clear that there is a lot of similarity between what happens behind the scenes when you either call 'f' or 'make-s'. Once 'a' and 'b' are supplied at call/instantiate time, there is enough information to compute 'c'.

You could think of instantiating a struct as being like a calling a function, and then storing the resulting symbolic environment for later use when the generated accessor functions are called. Or you could think of a evaluting a function as being like creating a hidden struct and then using it as the symbolic environment with which to evaluate the final result expression.

Is my toy model so oversimplified that it's useless? Or is it actually a helpful way to think about how real languages work? Are there any real languages/implementations that someone without a CS background but with an interest in programming languages (i.e. me) should learn more about in order to explore this concept?

Thanks.

EDIT: Thanks for the answers so far. To elaborate a little, I guess what I'm wondering is if there are any real languages where it's the case that people learning the language are told e.g. "you should think of objects as being essentially closures". Or if there are any real language implementations where it's the case that instantiating an object and calling a function actually share some common (non-trivial, i.e. not just library calls) code or data structures.

Does the analogy I'm making, which I know others have made before, go any deeper than mere analogy in any real situations?

Answer 1

You can't get much purer than lambda calculus: http://en.wikipedia.org/wiki/Lambda_calculus. Lambda calculus is in fact so pure, it only has functions!

A standard way of implementing a pair in lambda calculus is like so:

pair = fn a: fn b: fn x: x a b
first = fn a: fn b: a
second = fn a: fn b: b

So pair a b, what you might call a "struct", is actually a function (fn x: x a b). But it's a special type of function called a closure. A closure is essentially a function (fn x: x a b) plus values for all of the "free" variables (in this case, a and b).

So yes, instantiating a "struct" is like calling a function, but more importantly, the actual "struct" itself is like a special type of function (a closure).

If you think about how you would implement a lambda calculus interpreter, you can see the symmetry from the other side: you could implement a closure as an expression plus a struct containing the values of all the free variables.

Sorry if this is all obvious and you just wanted some real world example...

Answer 2

Both f and make-s are functions, but the resemblance doesn't go much further. Applying f calls the function and executes its code; applying make-s creates a structure.

In most language implementations and modelizations, make-s is a different kind of object from f: f is a closure, whereas make-s is a constructor (in the functional languages and logic meaning, which is close to the object oriented languages meaning).

If you like to think in an object-oriented way, both f and make-s have an apply method, but they have completely different implementations of this method.

If you like to think in terms of the underlying logic, f and make-s have a type build on the samme type constructor (the function type constructor), but they are constructed in different ways and have different destruction rules (function application vs. constructor application).

If you'd like to understand that last paragraph, I recommend Types and Programming Languages by Benjamin C. Pierce. Structures are discussed in §11.8.