[Melbourne-pm] Closures and scope warnings

Daniel Pittman daniel at rimspace.net
Wed Jul 28 22:41:00 PDT 2010

Toby Corkindale <toby.corkindale at strategicdata.com.au> writes:
> On 29/07/10 14:43, Daniel Pittman wrote:
>> Toby Corkindale<toby.corkindale at strategicdata.com.au>  writes:
>> [...]
>>> That's the "best practice" way to do transactions, I believe, but it does use
>>> a closure in a way that it wasn't really intended, I think?
>> I have no opinion on the wider discussion, but damn, what are they teaching in
>> those schools these days?
> Search me, when I was at school they were still teaching ADA83 and COBOL! (I
> might even have the textbooks gathering dust in an attic somewhere)
> I don't think either language supported Closures?
>> This is exactly what closures are for, up and up. :)
> Hurrah! Good to know then :)

Their original design was, basically, that you attach the code you write to a
GUI button, not a database transaction, but that the ability to capture
variables was (one of) the mechanisms recommended for external communication.

> They do strange things to my understanding and concepts of scoping
> though. Imagine if you called a recursive function, passing a closure
> around!  Mmm, tastes obfuscatory! :)

Hah.  Yeah, they make it necessary to regard the language as a graph of
objects tied together by their references to each other, instantiated from the
linear structure described in the source code.[1]

For bonus fun, play around with implementations of the Y combinator:

    "Although fixed point combinators are the standard solution for allowing a
     function not bound to an identifier to call itself, some languages like
     Javascript provide a syntactical construct which allows anonymous
     functions to refer to themselves."


[1]  ...or, at least, to have a mental model that is some approximation of
     that reality, even if you express it differently.

✣ Daniel Pittman            ✉ daniel at rimspace.net            ☎ +61 401 155 707
               ♽ made with 100 percent post-consumer electrons

More information about the Melbourne-pm mailing list