Re: Closures versus objects

On 15 Feb 2007, at 20:13, Mike Newhall wrote:

> 	Closures clearly can be used to make object-like things, and  
> objects can be used to make closure-like things.  Is one  
> demonstrably "better" than the other, in a theoretic or practical  
> sense, or both?

Closures are good at capturing bindings ("fields") without the need  
to declare what you want to capture upfront. If you change your mind  
about what to capture, there is only a single place that you have to  
change. It's so easy to do this that you typically don't even realize  
that your "objects" have changed their "layouts". With objects, when  
you want to create new ones that should get more fields, you have to  
change the corresponding class definition to do so as well (at least  
in the mainstream OOP languages).

Furthermore, closures are good at sharing bindings among each other.  
As an example in Scheme/Lisp, the following code creates two closures  
that capture the same binding:

(let ((x 42))
   (list (lambda () x) (lambda (y) (set! x y))))

A call to the second closure will have an effect on the result of  
calling the first one. With objects, you have to manually create  
"boxes" to be able to refer to the same memory locations (again, at  
least in mainstream OOP languages).

Objects are good at grouping several functions/methods. With a  
closure you get exactly one function that you can call, and if you  
want to invoke different kinds of functionality with that one  
function, you have to implement some kind of manual dispatch. With  
objects, you just call different methods, and the objects take care  
of dispatching to the right code.

> 	Concretely, from a language-design point of view, is it redundant  
> to include both features?  (assuming a "general purpose" language  
> is the goal, for some value of general)  Or is it merely  
> theoretically redundant, but in practice it is useful to have both?

As soon as your language is Turing-complete, anything you add is  
redundant. Language features are always only about convenience.

> 	Nevertheless closures would seem to have the edge when you need  
> something that behaves exactly like a function.  But some OO  
> languages allow you to invoke an object with function-like syntax.   
> In C++, this is merely syntactic sugar, but there's no reason a  
> language couldn't be designed to allow objects to be invoked in a  
> way semantically identical to functions (ignoring CLOS generics for  
> the moment, surely some OO languages already do this; Python?   
> JavaScript?),

Scala is also one of those. Also T, and the funcallable-standard- 
object substrate of the CLOS MOP.

> invoking some default method.  This equivalence can break down  
> however when, for example, an external entity like the OS requires  
> a callback function, and the semantics of invoking the callback are  
> outside the playpen where this equivalence is implemented, so that  
> only true closures would work in the context.  But this could be  
> said of many language features.  It's of particular concern in the C 
> ++ world where C calling conventions for OS callbacks are the norm  
> and object invocation is not an option.  (For that matter, any  
> language with closures attempting to use a C callback has to solve  
> this problem.)

Language interoperability is a concern for any pair of languages with  
features that are sufficiently different.

> 	Objects would seem to have the edge when you want the relationship  
> between functions that share state to be explicit both  
> syntactically and in the language.  This may be necessary to  
> enforce inheritance & access rules and so on.  Also it would seem  
> that if everyone rolled their own OO system with closures they  
> would inevitably be incompatible, although a standard library might  
> obviate that.

That's not so problematic when your main interface is that of a  
function call, like in CLOS or Dylan.

> 	As a perhaps separate thought, what are closures useful for?  That  
> is, for those of you who have had the luxury of programming in a  
> language with closures for many years, what uses have you found  
> that might not be obvious to programmers that have grown up closure- 
> deprived?  How would you "sell" closures to programmers steeped in  
> old habits?  What's your "Top 10" (or Top 3) list of the cases  
> where closures do the job better or make life easier?

a) Being able to create objects on the fly without having to worry  
about their structure (see above).

b) Providing functionality without having to worry that everyone uses  
the same / correct function names.


Pascal

-- 
Pascal Costanza, mailto:[email protected], http://p-cos.net
Vrije Universiteit Brussel, Programming Technology Lab
Pleinlaan 2, B-1050 Brussel, Belgium