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

[I'm starting to feel that this is wrong newsgroup for this discussion, but I'll defer to you. Set a follow-up if you like and I'll follow it there.]

Marshall <marshall.spight_at_gmail.com> wrote:
> My current somewhat stripped-down definition of a variable:
> something that can vary.

Right. Unfortunately, we still haven't reached a level of unambiguity. The word "vary" seems to have several fundemantally different meanings. In fact, I see two different usages of the term in the remainder of your article. Perhaps you can clarify what is meant. In the first sense, you say:

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

> 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.

So, in this case, the name 'x' within that scope can refer to different values in different contexts. In that sense, the meaning of x can vary not because it changes with time, but because it can be used in different contexts. Several of those contexts may even occur simultaneously.

> 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().

This seems to be a completely different use of the word 'variable'. Here the "vary" in variable seems to be restricted to varying with time. If one wants to call this a variable, it seems one would be forced to deny that 'x' is a variable in the first example. Instead, one would have to say that the name 'x' denotes different variables at different times; and, indeed, each of those could conceivably be a "first-class variable" in this latter sense in some possible language designs.

> Hmmm, well, the part of what Dale said that I was appreciating was
> the part about how closures and objects do very similar things,

Okay, point taken. I didn't notice that as the point so I skipped it; but I agree that it's true.

> and that a clean minimal language design won't have both.

I don't necessarily agree with this one. Languages have syntactic sugar all the time, and it's often helpful. I find it much nicer to program in Haskell rather than Lisp, for example, because the language is designed to offer a number of convenient syntax choices that don't increase the expressive power of the language at all.

In this case, I think there's even a bit more...

> (And if anything I think the syntax argument favors closures.)

I'd propose that it depends on what you're trying to do. I'm afraid I went too far in minimizing the choices involved in a previous post. Any use of OO concepts can be reproduced using function closures, and vice versa. By moving part of that implementation into the language itself, though, OO languages allow the implementation of certain specific patterns of message dispatch to be organized by the compiler in response to the result of global program analysis.

I understand the complaint that these patterns are chosen arbitrarily, having no sound theoretical basis; and that in choosing them, the OO religion then chooses to deny the possibility of using what remains. I am very much in agreement with those complaints. I also recognize, though, that those patterns of method dispatch were chosen because a lot of programmers tend to use them a lot; and that they do provide a benefit in that sense.

[...]
> 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>

My intuitive thought is that all programs have state at all levels of scope. It is reasonable to try to build a single fundamental abstraction to describe all of it; but it is not reasonable to try to eliminate it. Perhaps I'm misunderstanding you when you talk about local state, but I certainly wouldn't want to work in an environment where all state is global. That would be turning one's back on the direction of practically all progress in design of complex software to date.

-- 
Chris Smith