Re: Closure of lexical environment in Scheme closures

[Jamie Webb <j@...>]

On Fri, Nov 12, 2004 at 05:47:16AM +0000, Dr. Rich Artym wrote:
> On Thu, Nov 11, 2004 at 11:01:08PM +0000, Jamie Webb wrote:
> > Could you please define 'ordinary function'? And explain where that
> > definition came from?
> 
> Sure.  Lots of definitions coming up.

None of them the one I asked for...

> I wasn't using any esoteric meaning of "ordinary".  We were talking about
> closures as one very special (or at least specially named) kind of function,
> so I used "ordinary function" simply to mean anything that isn't a closure.

That's not a definition. So I'll assume we mean "value-returning,
possibly side-effecting subroutine", since that's the only way this
discussion seems to make sense. Notice that this is nothing like the
mathematical definition. It has none of the nice properties of the
mathematical definition. And you're (presumably) quite happy to use
it. So why is 'closure' sacred?

> After all, the word "closure" must mean something, otherwise why bother
> using it?  The plain unadorned word "function" would do just fine, if one
> is not referring to a closure.  So, let's assume that a "closure" is the
> special kind of function that 30+ years of literature has called a closure.

<snip lots of mostly inapplicable definitions>

> You may be right.  Unfortunately, there is only one way of interpreting
> it that makes it different from "ordinary function with free variables",
> because the definition of "free variable" is extremely precise across an
> immense and undisputed amount of published literature on the subject.

'Free variable' may be well-defined, but 'variable' is defined
differently in the pure and impure worlds.

> And therein lies the problem.  We're using the term "closure" for a Lua
> functional object which very testably has free variables in functions
> which, if they were closures, would have hardwired them in to the closed
> object that is the closure.

I think you're having trouble with the semantics of imperative
languages. In a functional language, an environment is a mapping from
names to values. In an imperative language, an environment is a
mapping from names to mutable memory locations. So the environment
/is/ closed, it just contains mutable variables. Just as when you
close over reference cells in ML or subsequently use set! in Scheme.

> If they haven't done this, then they haven't
> performed any closure.  I'm repeating myself, but this is so obvious that
> it's hard to say anything at all about it without doing so.

It's obvious given a pure functional language.

> In summary:  Lua "closures" aren't closures, they're "ordinary functions"
> containing variables which have not been closed, ie. with free variables.
> This isn't me being picky.  It's simply that they do not fulfil the most
> important property required of any closure, which is to be closed.

The problem is that you're assuming that closures imply referential
transparency, because the definitions that you insist on taking from
the functional world assume that. Referential transparency is not a
property that Lua (or indeed any other imperative language) has.
Period. Even if locals behaved as you want, there would still be
globals, tables, and the OS.

As I said, one might decide that closures are defined always to be
referentially transparent, though others would disagree, but claiming
the same about lexical scoping (and throwing in references to dynamic
scoping, which is very different), is just plain wrong.

-- Jamie Webb