On 28 Nov., 23:29, Meikel Brandmeyer <[EMAIL PROTECTED]> wrote:
> Hi André,
>
> Am 28.11.2008 um 22:56 schrieb André Thieme:
>
> >> Maybe I have a wrong understanding of "closure", but
> >> as far as I understand, every function definition in
> >> Clojure - be it defn or #() - finally translates to (fn ...).
> >> And fn creates a closure.
>
> I tooled myself up and looked up the definition of "closure"
> on Wikipedia. It seems that the definition says "one or more
> bound variables". I still don't see why the "empty" environment
> should that much of a special case. Why not just say:
> "a closure keeps its environment". Why should it matter
> whether its empty or not?
Because then having the word “closure” would be pointless.
We could go without it, or invent other words and use them
instead. In all programming languages all functions are always
closures without exception, if we won’t care.
However, if we take the definition of Wikipedia, then it really
makes sense, because you communicate to other programmers that
something is a specific function, with specific properties.
Wikipedia says:
“...a closure may occur when a function is defined within another
function, and the inner function refers to local variables of
the outer function.”
I agree with it.
I only stress the point more, that these local variables should
exist :-)
(instead of being the empty set, as in the example of Mark)
> > Well, from my experience I can say that a lot of people
> > think that “anon function = closure”, which would be
> > fn in Clojure or lambda in Common Lisp.
> > This however is not generally correct. In my previous
> > posting I gave an example of how a named function
> > became a closure.
>
> There is no thing like a named function. defn expands
> to (def ... (fn ...)). So an anonymous function is assigned
> to a Var which has a name.
defn is an abstraction to abstract these details away.
A macro like defn allows us to really have named functions,
it’s a new concept.
Of course, under the hood everything is just zeros and ones.
We know that and we can always switch the perspective from
which we look at things.
> anon function != closure.
This is nearly correct. Often anon functions are not closures.
But in some cases they can be.
> This happens to be a feature
> of Clojure, that it turns functions into closures.
It’s probably a different definition that we use for the
word “closure”. You define it as “function object”.
I define it as “function object that captures at least
one lexical variable of it’s environment”.
> Consider the GCC C extension for inner functions:
>
> struct some_thing
> do_something(int x)
> {
> int
> do_more()
> {
> return x + 1;
> }
>
> return call_with_fun_pointer(do_more);
>
> }
>
> do_more could be considered an "anonymous"
> function since it is only available inside do_something.
> But it is not a closure. Suppose call_with_fun_pointer
> stores away the pointer and returns.
>
> Calling do_more later on is invalid, because the
> stack was unwound and x doesn't exist anymore.
> This is exactly, what a closure prevents.
Yes.
My addition now is: do_something is also not a closure.
Closures are in the end lightweight objects.
So, we have minimal oop here.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~----------~----~----~----~------~----~------~--~---
