[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: What's so cool about Scheme?



Guy Steele wrote:
>    Mike Newhall wrote:
>    At 08:23 PM 2003.06.03 -0400, Anton van Straaten wrote:
>    >I can sort of agree with that, but really, without closures,
>    >people will - and do - use all sorts of hacks anyway -
>    >objects, for example ;o)
>
>    	As an aside, although I don't remember the exact argument, Christian
>    Queinnec in LISP In Small Pieces made the case that, although
>    many people consider objects to be 'poor man's closures', closures
>    are in fact poor man's objects (in his opinion).
>
> A closure is an object that supports exactly one method: "apply".

That's true from one perspective, and was what I was thinking of related to
objects being used as hacks to work around lack of closures.  A closure's
simplicity can be an asset: classes and interfaces can get in the way of
simple parameterization of behavior.  Anyone who's tried functional
programming in Java or C++ has encountered this - it can be done, but it's
more tedious.  If all you want to do is e.g. (map somefun mylist), being
able to concisely define executable "objects" (closures), inline if
necessary, is very useful.

But from another perspective, the apply "method" of a closure can be used as
a low-level method dispatch mechanism, so closures can be, and are, used to
implement very effective objects with multiple methods.  Oleg Kiselyov has a
short article on the subject:
http://okmij.org/ftp/Scheme/oop-in-fp.txt

Used in this way, closures can be said to be richer than objects because
they can support many more capabilities than just a single language-provided
method dispatch mechanism.  With closures seen as a building block with
which to implement objects, it's clear that objects are a poor man's
closures.

But a Smalltalker might say hold on, if you're going to all the trouble to
implement these closure thingies in your language, since they're already a
lot like objects, why not go all the way and make them "real" objects that
can support an arbitrary number of methods, so that a closure is just one
special-case kind of object?  If your language only has these restricted
closures, and you're forced to build an object system on top of them, it's
clear that closures are a poor man's objects.

Given this tension between opposites, I maintain that the question of
closures vs. objects should really be a koan.  I'll take some koanic license
and combine Norman Adams (alleged source of "objects are a poor man's
closures") and Christian Queinnec ("closures are a poor man's objects") into
a single great Zen language master named Qc Na.  I'll also take the
un-humble step of inserting myself as student, since as I mentioned in the
last paragraph of this message:
http://www.ai.mit.edu/~gregs/ll1-discuss-archive-html/msg01488.html
...I believe I did in fact gain some enlightenment from considering these
two apparently opposing positions.  Here goes:

* * *

  The venerable master Qc Na was walking with his student, Anton.  Hoping to
prompt the master into a discussion, Anton said "Master, I have heard that
objects are a very good thing - is this true?"  Qc Na looked pityingly at
his student and replied, "Foolish pupil - objects are merely a poor man's
closures."

  Chastised, Anton took his leave from his master and returned to his cell,
intent on studying closures.  He carefully read the entire "Lambda: The
Ultimate..." series of papers and its cousins, and implemented a small
Scheme interpreter with a closure-based object system.  He learned much, and
looked forward to informing his master of his progress.

  On his next walk with Qc Na, Anton attempted to impress his master by
saying "Master, I have diligently studied the matter, and now understand
that objects are truly a poor man's closures."  Qc Na responded by hitting
Anton with his stick, saying "When will you learn? Closures are a poor man's
object."  At that moment, Anton became enlightened.

:)