Re: Variables and closures (Was: Objects and Relations)

On Feb 10, 12:47 pm, Chris Smith <cdsm..._at_twu.net> wrote:
> Marshall <marshall.spi..._at_gmail.com> wrote:
>
> Sure. If you're trying to get across something more fundamental than
> whether "variable" should mean one thing or another, then that's worth
> discussing. It sounds like that's going on, although I've yet to hunt
> down what you mean by "first-class variable" in this context.

My current somewhat stripped-down definition of a variable: something that can vary.

This can actually be fairly subtle:

  const a := 3;
  const b := 2;

  add_one(x:int): int {
    x+1;
  }

  add_one(a);
  add_one(b);

Even if the language does not allow modification of function arguments (as if every argument was as Java's "final") we would still have to call
x in the above code a variable, even though we can never update x and even though x is only ever bound to things that themselves cannot be updated. It is a variable because it varies from one invocation of add_one to the next.

As to what I mean by "first-class" variable, I mentioned the wikipedia article on "first-classedness" of language constructs. A first class variable is a mutable store that can be passed as a parameter, put in a data structure, etc. Examples of first-class variables would include an ML ref cell, a Java or C++ object, or, at a very low level, the value returned from malloc().

> > Amusingly, whereas I once felt that Dale's excellent point
> > argued strongly against closures, I now feel that that point
> > argues strongly against objects and in favor of closures.
>
> I feel that Dale's point is just wrong. Clearly, contrary to what was
> stated there, objects and function closures are equally capable of
> expressing the same sets of abstractions. The only difference is one of
> terminology and syntax, which seems like a poor place to draw the battle
> lines.

Hmmm, well, the part of what Dale said that I was appreciating was the part about how closures and objects do very similar things, and that a clean minimal language design won't have both. Which I still think is a good point. However I agree with your critique about
the other stuff he said; they are "equally capable." (And if anything I think the syntax argument favors closures.)

> > It may also be timely to note that Neal Gafter is circulating
> > a proposal to add closures to Java.
>
> I've been waiting for someone
> to add closures to Java ever since Java 1.1 stuck its fingers in its
> ears and loudly screamed "we don't like closures" with that silly
> 'final' requirement for local and anonymous classes.

LOL. The thing is, though, that requiring variables closed over to be immutable makes the model a lot simpler; the so-called "upward funarg problem" completely vanishes, and that's not a trivial win, even in a GC language. To bring it back to relational theory somewhat, it also eliminates a problem in a relational language with first class functions and lexical scope, namely, what does it mean to put a closure into a relation? Relations classically have only pure value-semantics, and that is a big win in the simplicity department, both for the programmer's mental model and for implementations. I *really* hate to break that.

To state it another way, non-closure functions can be viewed precisely as relations, which unsurprisingly fits extremely well in a relational language. Closures cannot be so viewed; they are no longer simple values (whether we consider the extensional or the intentional value) but values + state. Ugh. My big complaint with OOPLs is the sprinkling of state all through the machinery of my program like sand in a complicated mechanism. A relational, value-semantics model completely eliminates this local state, sealing the mechanism I'm building against any impurities; closures break the seal! Bad closures.

But: they are probably too useful to be eliminated.</sob>

Marshall Received on Sat Feb 10 2007 - 23:00:52 CET