[Melbourne-pm] Closures and scope warnings
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.
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
functions to refer to themselves."
 ...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