Hi,
I have a confusion regarding closure and its definition. As per Paul
Graham:
When a function refers to a variable defined outside it, it’s called a
free variable. A function that refers to free lexical variable is
called a closure.
However as per CLHS a closure or lexical closure is:
lexical closure n. a function that, when invoked on arguments,
executes the body of a lambda
expression in the lexical environment that was captured at the time of
the creation of the lexical closure, augmented by bindings of the
function's parameters to the corresponding arguments.
lexical environment n. that part of the environment that contains
bindings whose names have lexical scope. A lexical environment
contains, among other things: ordinary bindings of variable names to
values, lexically established bindings of function names to functions,
macros, symbol macros, blocks, tags, and local declarations (see
declare).
Can any pro lisper kindly help me?
Thanks,
Samik
Blog: http://lispsamik.blogspot.com/
There is no universal definition of the concept of closure in the
context of programing languages.
Basically, if your language can define a function, and maitain a
permanent internal variable inside, it's closure.
For example, if you define a global var, and your function use access
and or set that global var, your function will be able to maintain a
state.
However, we all know global vars are bad because, for example, you
have this big pool where everyone and every function accesses... it's
hard to maitain and could be over-ridden by mistake...
So, a crude way to remedy this, is by following a convention, such
that any global var who's name starts with a 2 underscore is meant to
for special use. So, this way, you can have global vars __this ,
__that , __x, etc, and your function can call them. Now your function
can maintain a state, while the typical problem with using global vars
is avoided by a naming convention.
Now, effectively, your function is said to have “closure”. Typically,
that word is used when the language provide means to allow function to
have a state without the above hackish method. However, it's no more
complicated than that. In fact, it is effectively the only means to
implement closure. If the language hides such global vars from user,
and provide transparent ways when you create or access them inside
your function without the __ prefix, that's closure.
Once a functional language's funtion's has states, that is, having
closure, it is natural to extend the concept to become “objects” as in
Object Oriented Programing.
When you start to program in a way of closures, that is, a function
uses permant internal variables to maintain states, and you have many
functions like that, naturally, you might systematically explore this
paradigm. Namely, instead of just one or two permanent internal
variables, each of your function uses tens of such permanent internal
vars. This is the starting concept of so-called Object Oriented
Programing.
For detail and further explanation, see:
What are OOP's Jargons and Complexities
http://xahlee.org/Periodic_dosage_dir/t2/oop.html
--------------
Note: The terminology “Closure” is actually a very bad terminology. It
spreads endless confusion and non-understanding. See:
Jargons of Info Tech industry
http://xahlee.org/UnixResource_dir/writ/jargons.html
Math Terminology and Naming of Things
http://xahlee.org/cmaci/notation/math_namings.html
Xah
···@xahlee.org
∑ http://xahlee.org/
☄
On May 2, 1:31 am, Samik <······@gmail.com> wrote:
> Hi,
>
> I have a confusion regarding closure and its definition. As per Paul
> Graham:
>
> When a function refers to a variable defined outside it, it’s called a
> free variable. A function that refers to free lexical variable is
> called a closure.
>
> However as per CLHS a closure or lexical closure is:
>
> lexical closure n. a function that, when invoked on arguments,
> executes the body of a lambda
> expression in the lexical environment that was captured at the time of
> the creation of the lexical closure, augmented by bindings of the
> function's parameters to the corresponding arguments.
>
> lexical environment n. that part of the environment that contains
> bindings whose names have lexical scope. A lexical environment
> contains, among other things: ordinary bindings of variable names to
> values, lexically established bindings of function names to functions,
> macros, symbol macros, blocks, tags, and local declarations (see
> declare).
>
> Can any pro lisper kindly help me?
>
> Thanks,
> Samik
> Blog:http://lispsamik.blogspot.com/
On May 2, 11:02 am, ·······@gmail.com" <······@gmail.com> wrote:
> There is no universal definition of the concept of closure in the
> context of programing languages.
Fortunately there is. You just have to look it up.
> Basically, if your language can define a function, and maitain a
> permanent internal variable inside, it's closure.
>
> For example, if you define a global var, and your function use access
> and or set that global var, your function will be able to maintain a
> state.
Closures have nothing to do with global vars. Your attempt
to explain it does not help.
We can have different closures with the same function
and each has different variable bindings. Your global-variable-model
does not provide that.
(defun make-thing (name)
(flet ((local-function (message &rest args)
(case message
(:print (format t "Hi, I am ~a" name))
(:rename (setf name (first args))))))
#'local-function))
(make-thing "Red Chair") returns a closure.
(make-thing "Blue Chair") returns another closure.
Let's look inside:
? (describe (make-thing "Red Chair"))
#<COMPILED-LEXICAL-CLOSURE LOCAL-FUNCTION #x2AA04BE>
Name: LOCAL-FUNCTION
Inner lfun: #<Compiled-function LOCAL-FUNCTION (Non-Global)
#x2A9AFD6>
Closed over values
(0): "Red Chair"
? (describe (make-thing "Blue Chair"))
#<COMPILED-LEXICAL-CLOSURE LOCAL-FUNCTION #x2AA3C6E>
Name: LOCAL-FUNCTION
Inner lfun: #<Compiled-function LOCAL-FUNCTION (Non-Global)
#x2A9AFD6>
Closed over values
(0): "Blue Chair"
From the identifier you can see that both closures use the same 'Inner
lfun' #x2A9AFD6.
From the identifier you can see that both closures are different:
#x2AA04BE and #x2AA3C6E
The closures list different 'closed over values: "Red Chair" and "Blue
Chair".
Both closures have the same inner function (it is just one function)
but different variable bindings.
So, we have two closures, but only one inner function and two
different bindings.
Do you see the difference to your 'explanation'? It is not sufficient
that a function
has its own (uniquely named) global variables. You would need new
variables
every time a closure gets created.
Let's try your version:
(defparameter __name nil)
(defun make-thing (name)
(setf __name name)
(flet ((local-function (message &rest args)
(case message
(:print (format t "Hi, I am ~a" __name))
(:rename (setf __name (first args))))))
#'local-function))
(let ((a (make-thing :a))
(b (make-thing :b)))
(funcall a :print)
(terpri)
(funcall b :print))
Hi, I am B
Hi, I am B
Too, bad. Doesn't work. No closures.
? (describe (make-thing :A))
#<Compiled-function LOCAL-FUNCTION (Non-Global) #x2ADD4D6>
Name: LOCAL-FUNCTION
Arglist (analysis): (CCL::ARG-0 &REST CCL::THE-REST)
Again, no closure.
Above is btw. Common Lisp, which uses lexical binding by default
(different from Emacs Lisp)
and thus supports closures directly.
> --------------
>
> Note: The terminology “Closure” is actually a very bad terminology. It
> spreads endless confusion and non-understanding. See:
Your usual FUD. If you study the above example, you can end your
confusion.
...
Dear joswig,
i don't quite understand what you were saying, perhaps largely due to
your use of Common Lisp and jargons specific to it.
If you would, defend your thesis using plain English with good effort
at technical writing, or perhaps with emacs lisp code, then we can
start a debate.
if you think hard about closures, as if turning the concept into a
mathematical definition (aka formalization or codification), and
further, if you like, take a survey of say the top 10 major langs,
about their concept of closure (if any), further, then i think you'll
agree, that what i said about closures is perfect. Note the word
_perfect_ here. Its not _approximately right_, nor _helpful analogy_,
nor _insightful_. Perfect.
I am perfect.
Xah
···@xahlee.org
∑ http://xahlee.org/
☄
On May 2, 4:11 pm, ·······@corporate-world.lisp.de" <······@corporate-
world.lisp.de> wrote:
> On May 2, 11:02 am, ·······@gmail.com" <······@gmail.com> wrote:
>
> > There is no universal definition of the concept of closure in the
> > context of programing languages.
>
> Fortunately there is. You just have to look it up.
>
> > Basically, if your language can define a function, and maitain a
> > permanent internal variable inside, it's closure.
>
> > For example, if you define a global var, and your function use access
> > and or set that global var, your function will be able to maintain a
> > state.
>
> Closures have nothing to do with global vars. Your attempt
> to explain it does not help.
>
> We can have different closures with the same function
> and each has different variable bindings. Your global-variable-model
> does not provide that.
>
> (defun make-thing (name)
> (flet ((local-function (message &rest args)
> (case message
> (:print (format t "Hi, I am ~a" name))
> (:rename (setf name (first args))))))
> #'local-function))
>
> (make-thing "Red Chair") returns a closure.
> (make-thing "Blue Chair") returns another closure.
>
> Let's look inside:
>
> ? (describe (make-thing "Red Chair"))
> #<COMPILED-LEXICAL-CLOSURE LOCAL-FUNCTION #x2AA04BE>
> Name: LOCAL-FUNCTION
> Inner lfun: #<Compiled-function LOCAL-FUNCTION (Non-Global)
> #x2A9AFD6>
> Closed over values
> (0): "Red Chair"
>
> ? (describe (make-thing "Blue Chair"))
> #<COMPILED-LEXICAL-CLOSURE LOCAL-FUNCTION #x2AA3C6E>
> Name: LOCAL-FUNCTION
> Inner lfun: #<Compiled-function LOCAL-FUNCTION (Non-Global)
> #x2A9AFD6>
> Closed over values
> (0): "Blue Chair"
>
> From the identifier you can see that both closures use the same 'Inner
> lfun' #x2A9AFD6.
> From the identifier you can see that both closures are different:
> #x2AA04BE and #x2AA3C6E
> The closures list different 'closed over values: "Red Chair" and "Blue
> Chair".
>
> Both closures have the same inner function (it is just one function)
> but different variable bindings.
> So, we have two closures, but only one inner function and two
> different bindings.
>
> Do you see the difference to your 'explanation'? It is not sufficient
> that a function
> has its own (uniquely named) global variables. You would need new
> variables
> every time a closure gets created.
>
> Let's try your version:
>
> (defparameter __name nil)
>
> (defun make-thing (name)
> (setf __name name)
> (flet ((local-function (message &rest args)
> (case message
> (:print (format t "Hi, I am ~a" __name))
> (:rename (setf __name (first args))))))
> #'local-function))
>
> (let ((a (make-thing :a))
> (b (make-thing :b)))
> (funcall a :print)
> (terpri)
> (funcall b :print))
>
> Hi, I am B
> Hi, I am B
>
> Too, bad. Doesn't work. No closures.
>
> ? (describe (make-thing :A))
> #<Compiled-function LOCAL-FUNCTION (Non-Global) #x2ADD4D6>
> Name: LOCAL-FUNCTION
> Arglist (analysis): (CCL::ARG-0 &REST CCL::THE-REST)
>
> Again, no closure.
>
> Above is btw. Common Lisp, which uses lexical binding by default
> (different from Emacs Lisp)
> and thus supports closures directly.
>
> > --------------
>
> > Note: The terminology “Closure” is actually a very bad terminology. It
> > spreads endless confusion and non-understanding. See:
>
> Your usual FUD. If you study the above example, you can end your
> confusion.
>
> ...
On Fri, 2 May 2008 18:07:31 -0700 (PDT), ·······@gmail.com"
<······@gmail.com> wrote:
>Dear joswig,
>
>i don't quite understand what you were saying, perhaps largely due to
>your use of Common Lisp and jargons specific to it.
Rainer could have explained the concept without resorting to Lisp, but
apart from the lame attempt to relate closures to state, your
explanation was completely useless.
>If you would, defend your thesis using plain English with good effort
>at technical writing, or perhaps with emacs lisp code, then we can
>start a debate.
>
>if you think hard about closures, as if turning the concept into a
>mathematical definition (aka formalization or codification), and
>further, if you like, take a survey of say the top 10 major langs,
>about their concept of closure (if any), further, then i think you'll
>agree, that what i said about closures is perfect. Note the word
>_perfect_ here. Its not _approximately right_, nor _helpful analogy_,
>nor _insightful_. Perfect.
Your explanation was so off the mark as to be totally meaningless ...
not even just confusing ... totally meaningless.
>I am perfect.
A perfect imbecile maybe.
> Xah
George
> ···@xahlee.org
>? http://xahlee.org/
>
>?
>
>On May 2, 4:11 pm, ·······@corporate-world.lisp.de" <······@corporate-
>world.lisp.de> wrote:
>> On May 2, 11:02 am, ·······@gmail.com" <······@gmail.com> wrote:
>>
>> > There is no universal definition of the concept of closure in the
>> > context of programing languages.
>>
>> Fortunately there is. You just have to look it up.
>>
>> > Basically, if your language can define a function, and maitain a
>> > permanent internal variable inside, it's closure.
>>
>> > For example, if you define a global var, and your function use access
>> > and or set that global var, your function will be able to maintain a
>> > state.
>>
>> Closures have nothing to do with global vars. Your attempt
>> to explain it does not help.
>>
>> We can have different closures with the same function
>> and each has different variable bindings. Your global-variable-model
>> does not provide that.
>>
>> (defun make-thing (name)
>> (flet ((local-function (message &rest args)
>> (case message
>> (:print (format t "Hi, I am ~a" name))
>> (:rename (setf name (first args))))))
>> #'local-function))
>>
>> (make-thing "Red Chair") returns a closure.
>> (make-thing "Blue Chair") returns another closure.
>>
>> Let's look inside:
>>
>> ? (describe (make-thing "Red Chair"))
>> #<COMPILED-LEXICAL-CLOSURE LOCAL-FUNCTION #x2AA04BE>
>> Name: LOCAL-FUNCTION
>> Inner lfun: #<Compiled-function LOCAL-FUNCTION (Non-Global)
>> #x2A9AFD6>
>> Closed over values
>> (0): "Red Chair"
>>
>> ? (describe (make-thing "Blue Chair"))
>> #<COMPILED-LEXICAL-CLOSURE LOCAL-FUNCTION #x2AA3C6E>
>> Name: LOCAL-FUNCTION
>> Inner lfun: #<Compiled-function LOCAL-FUNCTION (Non-Global)
>> #x2A9AFD6>
>> Closed over values
>> (0): "Blue Chair"
>>
>> From the identifier you can see that both closures use the same 'Inner
>> lfun' #x2A9AFD6.
>> From the identifier you can see that both closures are different:
>> #x2AA04BE and #x2AA3C6E
>> The closures list different 'closed over values: "Red Chair" and "Blue
>> Chair".
>>
>> Both closures have the same inner function (it is just one function)
>> but different variable bindings.
>> So, we have two closures, but only one inner function and two
>> different bindings.
>>
>> Do you see the difference to your 'explanation'? It is not sufficient
>> that a function
>> has its own (uniquely named) global variables. You would need new
>> variables
>> every time a closure gets created.
>>
>> Let's try your version:
>>
>> (defparameter __name nil)
>>
>> (defun make-thing (name)
>> (setf __name name)
>> (flet ((local-function (message &rest args)
>> (case message
>> (:print (format t "Hi, I am ~a" __name))
>> (:rename (setf __name (first args))))))
>> #'local-function))
>>
>> (let ((a (make-thing :a))
>> (b (make-thing :b)))
>> (funcall a :print)
>> (terpri)
>> (funcall b :print))
>>
>> Hi, I am B
>> Hi, I am B
>>
>> Too, bad. Doesn't work. No closures.
>>
>> ? (describe (make-thing :A))
>> #<Compiled-function LOCAL-FUNCTION (Non-Global) #x2ADD4D6>
>> Name: LOCAL-FUNCTION
>> Arglist (analysis): (CCL::ARG-0 &REST CCL::THE-REST)
>>
>> Again, no closure.
>>
>> Above is btw. Common Lisp, which uses lexical binding by default
>> (different from Emacs Lisp)
>> and thus supports closures directly.
>>
>> > --------------
>>
>> > Note: The terminology �Closure� is actually a very bad terminology. It
>> > spreads endless confusion and non-understanding. See:
>>
>> Your usual FUD. If you study the above example, you can end your
>> confusion.
>>
>> ...
--
for email reply remove "/" from address
Dear George Neuner,
You and Rainer, are the epitomy of what i'd call the tech geeking
morons (or just “tech geekers”), in my eyes. That's the type of people
in computing industry, who can't see the gist of things, the context
of things, the purpose of things, but perpetually bury their heads
deep in technical obscurity.
(one quick way to picture this class of folks is to think of linuxers,
in the context of software usability (imagine, the worse scenario, if
your grandma calls in tech support asking about some problems with the
computer, and a tech geeker on the other end is yelling about jumpers
and drivers and kernel spaces running out of patience, quite
frustrated and aghast at the level of igorance and stupidity of people
in the world))
This class of folks, typically are slightly above average programers,
and some are academics. Most have been in the industry for a while.
Also, a significant percentage of them are a subset of studious
college students studying computer science. Put it in another way,
these tech geekers are a certain subset of elite programers, who pride
in calling themselfs “hackers”.
The tech geekers, their thinking and views are inline with orthodox
wisdom. They are also keen with the latest thinkings and trends and
thoughts, and pride themselfes in this fact of fashionability.
However, they have very little ability in creativity, or perspicacity.
Their IQ is often above average, but typically are not outstanding.
Also, their ability to analyze mathematically is low, possibly below
average among their intellectual peers. They never possess the acumen
typical of a mathematician.
However, a notable ability of tech geekers, is their tolerance for
dense, incomprehensible, obscure, technicalities. (perhaps that's is
also why they are good in their profession: coding) Specifically, the
ability to drill down dense technical details, often at the expense of
forgetting, discarding, or not understaning the context, whole design,
or original purpose. More often than not, a hallmark of their
foolhardiness caused by their tech drilling propensity, is that they
often create the most unusable software.
i have posted here actively for a month or so few months back. You
knew me, i knew you, we knew each other to some degree. So, instead of
starting another perhaps ultimately tiresome and useless argumentation
here about some computer science or programing subject, i thought i'd
write something else, just to be fresh, about what i think of your
cohorts as a class.
The usenet newsgroup comp.lang.* hierachy, are in fact a mecca for
this tech geeker class i speak of. In contrast, the tech geekers are
also almost never mathematicians, inventors, scientists. (For that
matter, nor ever sociologists, historian, good philosopher, or great
writers. O, and never artists of any standing.) I think a good
alternative epithet to convey the characteristics of this class of
people, is: Engineers. Of the nerdy, uncreative, brute force, ones.
Another tech geeker who was a regular here comes to mind. His name is
Christopher Brown. I wrote of him, in 2001, here:
• Unix and Literary Correlation
http://xahlee.org/UnixResource_dir/writ/unix_literary.html
Xah
···@xahlee.org
∑ http://xahlee.org/
☄
On May 2, 10:47 pm, George Neuner <·········@/comcast.net> wrote:
On Fri, 2 May 2008 18:07:31 -0700 (PDT), ·······@gmail.com"
<······@gmail.com> wrote:
>Dear joswig,
>i don't quite understand what you were saying, perhaps largely due to
>your use of Common Lisp and jargons specific to it.
Rainer could have explained the concept without resorting to Lisp, but
apart from the lame attempt to relate closures to state, your
explanation was completely useless.
>If you would, defend your thesis using plain English with good effort
>at technical writing, or perhaps with emacs lisp code, then we can
>start a debate.
>if you think hard about closures, as if turning the concept into a
>mathematical definition (aka formalization or codification), and
>further, if you like, take a survey of say the top 10 major langs,
>about their concept of closure (if any), further, then i think you'll
>agree, that what i said about closures is perfect. Note the word
>_perfect_ here. Its not _approximately right_, nor _helpful analogy_,
>nor _insightful_. Perfect.
Your explanation was so off the mark as to be totally meaningless ...
not even just confusing ... totally meaningless.
>I am perfect.
A perfect imbecile maybe.
> Xah
George
On May 3, 10:34 am, ·······@gmail.com" <······@gmail.com> wrote:
...
> i have posted here actively for a month or so few months back. You
> knew me, i knew you, we knew each other to some degree. So, instead of
> starting another perhaps ultimately tiresome and useless argumentation
> here about some computer science or programing subject, i thought i'd
> write something else, just to be fresh, about what i think of your
> cohorts as a class.
>
> The usenet newsgroup comp.lang.* hierachy, are in fact a mecca for
> this tech geeker class i speak of. In contrast, the tech geekers are
> also almost never mathematicians, inventors, scientists. (For that
> matter, nor ever sociologists, historian, good philosopher, or great
> writers. O, and never artists of any standing.) I think a good
> alternative epithet to convey the characteristics of this class of
> people, is: Engineers. Of the nerdy, uncreative, brute force, ones.
...
Lisp is a programming language. That means it is thought for writing
software and communicating ideas through software. All kinds of
software.
There is no limit.
This means that others will read code. I find the idea of using Lisp
as
a way to communicate ideas to be very important. This is assumes
that the target audience makes some effort to understand the language
and the author makes some effort to communicate clearly.
For me this means that comp.lang.lisp is a place where Lisp users
discuss all kinds of problems related to Lisp programming (technical,
social, ideas, ...). So in my postings I try not to abstractly talk
about Lisp, but give real code examples and discuss real code
examples.
Not that my code is the best, but others can look at it and
think about it - either it helps them or they can give me feedback
about my own understanding. Actually I try less to write about
social problems - others are doing this already. ;-)
If you ever want to be productive with Lisp (opposed to
say, script Emacs or write Mathematica code), you should start
thinking and writing in Lisp code. Your attempts at scripting
Emacs is a useful start.
·······@gmail.com" <······@gmail.com> writes:
<snipped a whole lot of irrelevant ravings>
Xah,
Rainer provided a very concise and clear explination of why your
definition was overly simplistic and failed to really explain
closures. He gave a clear high level english explination which was not
overly burdened with what you mistakenly call tech geek speak and he
provided clear examples using CL of both his more comprehensive
explination and why yours was insufficient.
Instead of reverting to attacking him on a personal basis, why not
address what he wrote? Is that because you know he is correct or is it
because you don't have the intelect to understand his clear explination?
You claim your 'perfect'and your definition was perfect, then why not
prove it? Rainer provided a very simple example of where your definition
fails - address that and prove your claims.
In fact, here is a challenge for you. You claim there are too many 'tech
geeks' who insist on confusing everyone and making explinations too
technical in order to show off their superiority and create an elitist
style of environment that mainly aims to shut out the less technically
oriented etc. Well, here is your chance to prove your point. Provide a
clear and concise explination of closures that doesn't have the obvious
wholes that Rainer pointed out and do so in a clear and concise manner
that doesn't have the tech geek orientation you typically accuse others
of when they challenge you. Rather than immediately becoming defensive
as soon as your criticised, especially when that criticism comes with
constructive and clear explination, consider what they have written in
an objective and less emotional manner and improve your definition.
If you can do that, not only will you add to yor credibility, but you
will also provide something valuable for those you claim to be
attempting to help. Put your ego aside and see what truely positive
contribution you can make. I would also suggest you get a native english
speaker to help as your written communication is quite poor despite its
overwhelming quantity. Clear writing is a difficult skill to master and
even the very best have to work at improving their skills. You are a
long way from perfect. The first step to getting better is to realise
that.
Tim
--
tcross (at) rapttech dot com dot au
It's deja vu all over again.
I feel like i'm a genius, even though i'm really not, but now it
appears here, there are 4 against me now, and who are these 4 people?
they are (mostly) experienced lisp programers.
If there are 4 lisp programers, most or all of which i think are
experienced, and all claim that i was wrong, how can i be right?
<<Laughs out loud to myself a nervous laugh>>
So, logic must dictate, that i'm a real genius, that my thoughts are,
as they say, beyond the times, transcents the common.
At this point, i have maybe 2 choices. (1) to continue my aloof
existance, and keep exuding heightened phantasmagorical writings. (2)
to be down to earth, and explain in earnest, technically, my positions
in a humble way, with the consequences of (A) utterly proven myself to
be the biggest idiot who made a big splash but shown to be wrong, at
the end. (B) proven my distractors wrong, and hence earns the
admiration and respect with mystic qualities.
This is a dire decision to make. I seems to be unable to make this
decision. Could this be a false dilemma?
I'm guessing my problem has to do with my personality. A normal
person, would probably just discuss the issue in earnest. Like, we all
human beings, some knows some areas better, and we all make mistakes.
A discussion can just carry on in its course, and everyone can just
learn something or simply enjoy the conversation.
But Noooo! I can't be like that. People have wronged me. Not because
i'm wrong, because they are cocks (and comparatively stupid?). Look at
Rainer's reply to my message, he called me FUD!! He called me FUD,
everybody! Look there!!!
He sayz: «Fortunately there is. You just have to look it up. »
Now that tone is not pleasant on the ear! I said «There is no
universal definition of the concept of closure in the context of
programing languages.» and he retorted me and denied me the pleasure
to be correct!
He continues: «Closures have nothing to do with global vars. Your
attempt to explain it does not help.»
Woot! Perhaps his writing skill at the precision aspect needs
improving, but i don't think my writing claimed that “closures has to
do with global vars” (nay, i knew i didn't). He sayz my attempt to
help didn't help. He sullied me! I got sullied. Wrongfulness accused.
Incompetence of fact-checking charged. I got WRONGED AND SULLIED.
DENIED the pleasure of helping! A fundamental pleasure of life, denied
to me, by one tech geeker.
I refused to believe this, and i kindly told Rainer that he should
think about the issue, to formalize the concept, to take a survey, and
i'm perfect. Now, one George tech geeker ganged on me and propound
that i'm a “perfect imbecile”!
Witnesses, you have seen the above. The sequence of affairs is not
unlike a pack of dogs barking for supremacy. I imagine i still have
the upper hand though.
Still, it troubles me deeply, how could a patently simple explanation,
a simple concept, a penetrating view, be not clearly grasped by a
gaggle of lispers? In this thread, there are 15 messages. Not one
reply, seems to indicate that what i said is correct. Almost half of
them actually pointed out that i was incorrect, and even unhelpful.
I'm greatly troubled by this. To me, this is like going into a bar,
and when the subject of 1+1 comes up, my nonchalant remark of 2
suddently made everybody stare. This can be a terrifying experience.
Like, in a bar you suddenly realized all the people around you are not
humans but aliens. Or, you realized it's a gay bar and you are not
gay. Or, they are all black and you are the only white. Or, you are
standing out like a sole genius.
Suppose, in such a situation, you have some choices. A rational one,
is to calmly explain, in earnest, your views. And, you think, truth
will prevail. But nuuuuu! What if they will have none of it? I mean,
for all you know, these aliens might be cannibals. And remember, you
are out numbered. Just imagine, 50 bucks on a doe; the lord of the
flies. A alternative course of action, is to ply the art of
subterfuge. Feign left and right, give a smile and a nod. Acknowledge,
that 1+1 can be 3, under the circumstances. Tech geek with them. Win a
friend.
Sirs, would you like to have a piece of my mind?
Xah
···@xahlee.org
∑ http://xahlee.org/
☄
On May 4, 12:21 am, Tim X <····@nospam.dev.null> wrote:
> ·······@gmail.com" <······@gmail.com> writes:
>
> <snipped a whole lot of irrelevant ravings>
>
> Xah,
>
> Rainer provided a very concise and clear explination of why your
> definition was overly simplistic and failed to really explain
> closures. He gave a clear high level english explination which was not
> overly burdened with what you mistakenly call tech geek speak and he
> provided clear examples using CL of both his more comprehensive
> explination and why yours was insufficient.
>
> Instead of reverting to attacking him on a personal basis, why not
> address what he wrote? Is that because you know he is correct or is it
> because you don't have the intelect to understand his clear explination?
> You claim your 'perfect'and your definition was perfect, then why not
> prove it? Rainer provided a very simple example of where your definition
> fails - address that and prove your claims.
>
> In fact, here is a challenge for you. You claim there are too many 'tech
> geeks' who insist on confusing everyone and making explinations too
> technical in order to show off their superiority and create an elitist
> style of environment that mainly aims to shut out the less technically
> oriented etc. Well, here is your chance to prove your point. Provide a
> clear and concise explination of closures that doesn't have the obvious
> wholes that Rainer pointed out and do so in a clear and concise manner
> that doesn't have the tech geek orientation you typically accuse others
> of when they challenge you. Rather than immediately becoming defensive
> as soon as your criticised, especially when that criticism comes with
> constructive and clear explination, consider what they have written in
> an objective and less emotional manner and improve your definition.
>
> If you can do that, not only will you add to yor credibility, but you
> will also provide something valuable for those you claim to be
> attempting to help. Put your ego aside and see what truely positive
> contribution you can make. I would also suggest you get a native english
> speaker to help as your written communication is quite poor despite its
> overwhelming quantity. Clear writing is a difficult skill to master and
> even the very best have to work at improving their skills. You are a
> long way from perfect. The first step to getting better is to realise
> that.
>
> Tim
>
> --
> tcross (at) rapttech dot com dot au
······@gmail.com wrote:
> It's deja vu all over again.
>
> I feel like i'm a genius, even though i'm really not, but now it
> appears here, there are 4 against me now, and who are these 4 people?
> they are (mostly) experienced lisp programers.
>
> If there are 4 lisp programers, most or all of which i think are
> experienced, and all claim that i was wrong, how can i be right?
>
> <<Laughs out loud to myself a nervous laugh>>
>
> So, logic must dictate, that i'm a real genius, that my thoughts are,
> as they say, beyond the times, transcents the common.
>
> At this point, i have maybe 2 choices. (1) to continue my aloof
> existance, and keep exuding heightened phantasmagorical writings. (2)
> to be down to earth, and explain in earnest, technically, my positions
> in a humble way, with the consequences of (A) utterly proven myself to
> be the biggest idiot who made a big splash but shown to be wrong, at
> the end. (B) proven my distractors wrong, and hence earns the
> admiration and respect with mystic qualities.
>
> This is a dire decision to make. I seems to be unable to make this
> decision. Could this be a false dilemma?
>
> I'm guessing my problem has to do with my personality. A normal
> person, would probably just discuss the issue in earnest. Like, we all
> human beings, some knows some areas better, and we all make mistakes.
> A discussion can just carry on in its course, and everyone can just
> learn something or simply enjoy the conversation.
>
> But Noooo! I can't be like that. People have wronged me. Not because
> i'm wrong, because they are cocks (and comparatively stupid?). Look at
> Rainer's reply to my message, he called me FUD!! He called me FUD,
> everybody! Look there!!!
>
> He sayz: «Fortunately there is. You just have to look it up. »
>
> Now that tone is not pleasant on the ear! I said «There is no
> universal definition of the concept of closure in the context of
> programing languages.» and he retorted me and denied me the pleasure
> to be correct!
>
> He continues: «Closures have nothing to do with global vars. Your
> attempt to explain it does not help.»
>
> Woot! Perhaps his writing skill at the precision aspect needs
> improving, but i don't think my writing claimed that “closures has to
> do with global vars” (nay, i knew i didn't). He sayz my attempt to
> help didn't help. He sullied me! I got sullied. Wrongfulness accused.
> Incompetence of fact-checking charged. I got WRONGED AND SULLIED.
> DENIED the pleasure of helping! A fundamental pleasure of life, denied
> to me, by one tech geeker.
>
> I refused to believe this, and i kindly told Rainer that he should
> think about the issue, to formalize the concept, to take a survey, and
> i'm perfect. Now, one George tech geeker ganged on me and propound
> that i'm a “perfect imbecile”!
>
> Witnesses, you have seen the above. The sequence of affairs is not
> unlike a pack of dogs barking for supremacy. I imagine i still have
> the upper hand though.
>
> Still, it troubles me deeply, how could a patently simple explanation,
> a simple concept, a penetrating view, be not clearly grasped by a
> gaggle of lispers? In this thread, there are 15 messages. Not one
> reply, seems to indicate that what i said is correct. Almost half of
> them actually pointed out that i was incorrect, and even unhelpful.
> I'm greatly troubled by this. To me, this is like going into a bar,
> and when the subject of 1+1 comes up, my nonchalant remark of 2
> suddently made everybody stare. This can be a terrifying experience.
> Like, in a bar you suddenly realized all the people around you are not
> humans but aliens. Or, you realized it's a gay bar and you are not
> gay. Or, they are all black and you are the only white. Or, you are
> standing out like a sole genius.
>
> Suppose, in such a situation, you have some choices. A rational one,
> is to calmly explain, in earnest, your views. And, you think, truth
> will prevail. But nuuuuu! What if they will have none of it? I mean,
> for all you know, these aliens might be cannibals. And remember, you
> are out numbered. Just imagine, 50 bucks on a doe; the lord of the
> flies. A alternative course of action, is to ply the art of
> subterfuge. Feign left and right, give a smile and a nod. Acknowledge,
> that 1+1 can be 3, under the circumstances. Tech geek with them. Win a
> friend.
>
> Sirs, would you like to have a piece of my mind?
I thought we just did. And it was great. Post on, O Mighty Xah!
I am fascinated by the evidence of soaring social IQ, so high now that
the question of how best to react to reactors distracts from the OQ of
closures. Computers are easy to figure out, but people? Omigod! Now
there is a challenge for any genius in one domain but not others
(Gardner found six).
If I want to improve my lot the most lucrative field of study will be
the one in which I am most deficient: it would be much easier for me to
improve my unicycling than my Lisp never having been on a unicycle. But
with people the stakes are higher than the unicycle.
Above we hear one option to "continue my aloof existence", below we have
another -- "Win a friend.". The evidence I spoke of is these even being
considered. The monk (perhaps wisely!) has taken the easy way out,
abandoning the challenge altogether and at the extreme retiring to a
monastery where one does not speak. But I hear a yearning in the word
"aloof" and in the conjunction of "win" and "friend" and why does "vow
of silence" and "Xah Lee" sound so wrong?
I went woodshed (its a jargon thing) on stand-up recently, found two
things: the audience is all that matters and (2) never mind the
audience, you are right, they are wrong. Reconciliation below.
Most people were disapoointed by my talk at ECLM 2008, a fumbling
walkthru of Cells and a quick look at my Algebra app. Apparently they
were all primed for a dancing bear, and I just talked about the single
most powerful software library one could use. Six liked it and wanted to
talk afterwards, ninety hated it. The organizers want the airfare back.
Otoh, the folks lucky enough to be at the stern of boat #1 and the great
crowd that heeded my ensuing pied piper procession to the bar nearest
the dock got the show.
The moral?
(1) The audience is all that matters, but they respond only to truth. I
have to get the audience, but I must use non-subterfuging subterfuge.
This is the actors problem, to act and be real at once. Brando
dumbfounded Cavett for an hour trying to convince him that Cavett --
simply by being a person -- was as great an actor as anyone.
(2) Next time Kenny yells "Let's go drinking!" at the end of the night,
go drinking.
hth, kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
On Sun, 4 May 2008 08:02:23 -0700 (PDT), ·······@gmail.com"
<······@gmail.com> wrote:
>
>Still, it troubles me deeply, how could a patently simple explanation,
>a simple concept, a penetrating view, be not clearly grasped by a
>gaggle of lispers? In this thread, there are 15 messages. Not one
>reply, seems to indicate that what i said is correct. Almost half of
>them actually pointed out that i was incorrect, and even unhelpful.
>I'm greatly troubled by this. To me, this is like going into a bar,
>and when the subject of 1+1 comes up, my nonchalant remark of 2
>suddently made everybody stare. This can be a terrifying experience.
>Like, in a bar you suddenly realized all the people around you are not
>humans but aliens. Or, you realized it's a gay bar and you are not
>gay. Or, they are all black and you are the only white. Or, you are
>standing out like a sole genius.
You _are_ incorrect. Following some factually correct but irrelevant
information about naming conventions, you said:
"If the language hides such global vars from user,
and provide transparent ways when you create or
access them inside your function without the __
prefix, that's closure."
Conceptually, closures create a parameterized instance of a function
by capturing the values of the function's free variables. As a
technical matter, closures were specifically created to address the
problem of "non-local" lexically scoped variables. Globals are free
variables but they are not considered to be "non-local" in the lexical
sense.
There is no technical reason why closures could not also capture
globals (the top-level is a lexical scope after all), but there is a
semantic reason not to. The variables in each lexical scope can be
thought of as out-of-band communication channels for parts of the
program contained within the scope. If all free variables were to be
captured, there would be no way to communicate out-of-band data[*].
Globals, in particular, are considered to be for communication between
different parts of the program, so globals are treated specially and
are not captured by closures.
[*] some people would consider that a Good Thing(tm).
George
--
for email reply remove "/" from address
George Neuner wrote:
> Conceptually, closures create a parameterized instance of a function
> by capturing the values of the function's free variables.
Not sure this matters, but it is not just the values being captured, it
is the variables themselves, for I can assign to them and might share
them with other closures.
kt
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
From: Kent M Pitman
Subject: Re: A question (confusion) about closure
Date:
Message-ID: <utzhdb56d.fsf@nhplace.com>
Ken Tilton <···········@optonline.net> writes:
> George Neuner wrote:
> > Conceptually, closures create a parameterized instance of a function
> > by capturing the values of the function's free variables.
>
> Not sure this matters, but it is not just the values being captured,
> it is the variables themselves, for I can assign to them and might
> share them with other closures.
The point you make is valid, but I'm not sure if it matters either,
but mostly only because Xah's writing is just so hard to read that
it's hard to tell WHAT is relevant.
It saddens me actually, because it sounds like he actually thinks
about a bunch of issues, and has a lot of energy that is frittered
away in unproductive fashion. I think it's very hard for people to
agree with him when they can't tell what he's saying--at least, I
can't. I think he sometimes covers for less strong English
composition skills by smokescreens built of personality flair, but
he'd benefit from some honest self-reflection on whether confronting
the communication problem more directly wouldn't help him. I don't
think people would mind talking to him as much if he were less
flippant about the fact that he's just plain unintelligible a lot, and
less willing to blame that on other people.
In the end, people fail to agree with him, and he mistakes that for
them disagreeing with him, which is a subtle wording difference, but
not at all the same thing in practice. And he often appears sure that
what he MEANS is right, which it might be, for all I can tell. If he
can't express it well enough to tell, though, it's hard to go much
farther.
To the point in this thread, he's made some remarks about global
variables that may be reasoned or may not, but that are certainly not
clearly enough presented to know what in fact he is saying. Then he
makes fun of and offers active annoyance at people who've gone out of
their way to engage him rather than dismiss him, trying to ferret out
what he might be saying.
His remarks on closures vs object-oriented systems might be general
confusion about what happens presently, or might just be speaking
abstractly about concepts, and in the latter situation, might or might
not be reasonable observations. It's just hard to tell.
To Kenny's comment above, the relevance seems to be that
(defun foo (x) y)
means more than
(subst <some-value> 'y '(defun foo (x) y))
but indeed means that should y be given a new value through program
execution, foo will see that new value. I'm pretty sure that Xah as
much as said this.
I couldn't figure out what the __ stuff was about. It might have been
a restatement of the *...* idea. Or it might have been saying that a
closure was only ever used like:
(defun foo (y) (setq x y))
(defun bar () x)
(list (foo 3) (bar) (foo 4) (bar))
=> (3 3 4 4)
and that globals would live in __x and that other variables would be
created locally, as if in the FOO definition above, the x would be created
locally to FOO, not globally, because it had no special marker saying he
wanted the global variable, as if it meant
(defun foo (y)
(let ((x y))
x))
but then again... he might not have meant that. His writing doesn't allow
me to tell.
It's an open question whether he can tell whether
(defun foo (x) (lambda () x))
gives a function where the x storage location is new each time foo is
called, because at least one reading of his writing is that he thinks
the free x in (lambda () x) might somehow [as a closure variable] refer
to some __x secret global place that variables get put. This would be kind
of like a weird gosub kind of thing I think I've seen in some old BASIC
variants where function arguments weren't really "bound" but were rather
names of global variables to set on entry to the function, so that
defining
(defun foo (x) (+ x 3))
(defun bar () (foo 4))
and then calling
(bar)
was really the same as writing:
(defun foo () (+ __x 3))
(defun bar () (setq __x 4) (foo))
(bar)
I don't think this is what Xah means, mostly because I think he's
smarter than to think this. But his wording is vague enough that I
think it would support some odd readings in this area. And under this
reading, he'd be missing the point that (defun foo (x) (lambda () x))
means that (foo 3) and (foo 3) actually return closures over a different
x, not over a common x.
I will say that many years back, I was talking to Bob Kerns (RWK) when
we were both working at Symbolics [he and I also worked together at
MIT and he taught me a great deal about Lisp in my formative years]
and the topic of the day was a function called dw:accept-2 or
something like that, I'm not sure I'm remembering the name right... it
was part of the internals of the accept substrate of Dynamic
Windows. He had identified it as the largest single function
definition in Symbolics Genera. It had clearly gotten out of hand.
He said to me that if he had it to do over again, he'd have written it
as a flavor [i.e., a "class" in CLOS terminology; DW was written in
Zetalisp, which was based on Flavors--probably New Flavors by the time
of this discussion, but it was the same basic idea]. This took me
aback because I had never clearly understood that a closure was really
just a vague kind of anonymous, opaque class. Probably I should have
noticed this ages before, since I had at that point been programming
in CL for 10 years or so, but I hadn't ever really thought about it in
such concrete terms. I understood instantly what he was saying,
though, and it was quite an epiphany. It would never have occurred to
me to rewrite something involving closures as something involving
flavors/classes, but it seemed obviously right when he mentioned it.
Closures offer variables that hold (as Xah seems to be alluding to, if
I can understand what he's running on about) state. And classes have
the additional feature that the state is more "out in the open", if
you will, especially since in CL one can always get in and use
WITH-SLOTS [as opposed to languages like Java and C# where you can
find yourself "locked out" of your class if you were not there at time
of definition and didn't make something public. I had the vaguest
sense that Xah was using the term "closed" to mean "encapsulated", and
if you make this relation between closures and classes, then you can
sort of see the analogy, even though it is syntactically different
than how Lisp texts usually talk about it. So maybe this is the
observation that Xah is making. Or maybe it's related. Or maybe not.
Who can tell? It's a pity.
As a matter of practice, one cannot credit another with being right in
an academic or technical discussion merely because they have said
something vague and that vague thing is not inconsistent with an
epiphany. If one could get such credit, then I would say things like
"We need to invent a better power supply." and then claim credit for
solving a major piece of the climate change problem, while meanwhile
just chiding people all along for not understanding the detail of my
remark... The credit goes to the first person to describe how to do
that in a clear manner that can be executed upon unambiguously by more
than one person working in isolation, not to the first person who says
something so vague that it merely spans the relevant problem space.
But what's a worse pity is that Xah can't acknowledge others' attempts
to engage him for what those attempts are--a friendly act. He seems to
feel compelled to bat back the very people who are doing the most work
to treat him like a human being. Much more than he sometimes gives
the impression he's doing for them. I fully expect he'll explain to
me why I'm a loser for writing this piece, which is intended not to
make him feel bad, but rather to encourage him to take constructive
action that would improve his overall ability to interact with the
community constructively. All of this just my personal opinion, of
course. Your (and his) mileage may vary. Ah well. At least I tried.
i'm rather quite surprised how my exposition of the closure concept
turn up so many messages, many claiming it being even unhelpful or
useless. And now, Kent, the rhetoric master, began his verbose
elaboration with my name repeatedly embeded. (i feel, rather, elated
by that) (lol)
in the beginning, 'was just Rainer and George Neuner. Their problem,
is simply not seeing the over all picture, but drilling on Common Lisp
technicality and terminology. I point this out but, but as i said,
sometimes something so obvious and clear to me but can't get other
programers to see. (lisp's cons and list problem, is another example,
we've discused at length around Jan) Robert Maas came in too. So
silly.
People, closures is effectively just function using global vars,
alright?
You want functions to share env? create a naming scheme like
_contextA_var1, _contextA_var2, ... then functions can share
_contextA_* vars.
You want 2 different env? have it _contextA_*, _contextB_* ... etc.
You want nesting? Have it _contextA_ContextA_*...,
_contextA_ContextB_*..., _contextA_ContextA_ContextA*,
_contextA_ContextA_ContextB*, ..., etc.
No, the prefix “_” isn't alluding to Python's object whatnot or
anything. It just any random string as a naming convention so it could
be programatically identified and hidden from user. (think how you
would implement closure)
In this way, you have closures, or what closures is supposed to
achieve in a program, in just about any language.
Closures, function with a state, OOP, are basically the same thing.
They just have slightly different perspective, slightly different
connotation, and defined and implemented differently in different
langs.
When you formalize them into mathematics, they amount to the same
thing.
People, stop tech geeking. Get ya heads out of sand. Stop drilling on
definitions and terminologies, or burying yourself deep inside Common
Lisp. The originall poster of this thread is perhaps asking about
terminologies in CL context and i hijacked the thread to discuss the
concept of closure itself in general. At least i wished you could see
that.
The Kent Pitman fella is a pest. He is the circular priest. Writes
long and carefully, and very difficult to deal with. Whatever he
didn't like, will become the lamb to be put up for slaughter when the
time comes.
The Rainer fella insists his posting of Common Lisp code as a way to
put the discussion on firm grounds. What a meritable fellow. Try Emacs
Lisp Rainer, or Mathemtica. If you have a question on the latter, i
can help you.
Tim X, shuddap and go do your school work.
Kenny!!!!!! I saw your vid on google. On the beach babbling about the
wonders of Common Lisp. You crazy!!!!
Xah
···@xahlee.org
∑ http://xahlee.org/
☄
······@gmail.com wrote:
> i'm rather quite surprised how my exposition of the closure concept
> turn up so many messages, many claiming it being even unhelpful or
> useless. And now, Kent, the rhetoric master, began his verbose
> elaboration with my name repeatedly embeded. (i feel, rather, elated
> by that) (lol)
>
> in the beginning, 'was just Rainer and George Neuner. Their problem,
> is simply not seeing the over all picture, but drilling on Common Lisp
> technicality and terminology. I point this out but, but as i said,
> sometimes something so obvious and clear to me but can't get other
> programers to see. (lisp's cons and list problem, is another example,
> we've discused at length around Jan) Robert Maas came in too. So
> silly.
>
> People, closures is effectively just function using global vars,
> alright?
Possibly not. It depends on how you mean this naming scheme of yours to
work (the meta-problem being you not accepting CL as the way to make
concrete hence comprehensible normally incomprehensible natural
language, but let's soldier on with sign language and see what can be
achieved)...
>
> You want functions to share env? create a naming scheme like
> _contextA_var1, _contextA_var2, ... then functions can share
> _contextA_* vars.
>
> You want 2 different env? have it _contextA_*, _contextB_* ... etc.
If you at least show us the actual Python code we could understand you
better. What I would be looking for is...well, lemme ask: Do you mean
that "different env" would be achieved by generating unique names /on
each dynamic entry/ into the same block of code, by mucking with the
Python dictionary?
(defparameter *xah-space* (make-hash-table :test 'equalp))
(map nil 'funcall
(loop for x below 2
collecting
(let ((yvar (concatenate 'string
(symbol-name (gensym))
"-var1")))
(setf (gethash yvar *xah-space*) x)
(lambda ()
(print `(y is ,(gethash yvar *xah-space*)))))))
->
(Y IS 0)
(Y IS 1)
Or did you mean "different env" would be achieved by hard-coding
_contextA_var1 one place in the code and hard-coding _contextB_var1
another place in the code?
The latter (hardcoding differently prefixed "var1"s) does not cut it,
but in the former you are Greenspunning closures (but need to work out
when to GC the unique names or in a sufficiently heavy-hit function your
Python dictionary will explode).
You have mentioned Emacs Lisp as a satisfactory form of communication,
perhaps someone could offer this in Emacs form:
(map nil 'funcall
(loop for x below 2
collecting (let ((y x))
(lambda () (print `(y is ,y))))))
->
(Y IS 0)
(Y IS 1)
Again, you can Greenspun that with a dictionary and GCing the globals
(much harder--when does the anonymous function itself get GCed?), but
maybe you did not mean that.
>
> You want nesting? Have it _contextA_ContextA_*...,
> _contextA_ContextB_*..., _contextA_ContextA_ContextA*,
> _contextA_ContextA_ContextB*, ..., etc.
>
> No, the prefix “_” isn't alluding to Python's object whatnot or
> anything. It just any random string as a naming convention so it could
> be programatically identified and hidden from user. (think how you
> would implement closure)
>
> In this way, you have closures, or what closures is supposed to
> achieve in a program, in just about any language.
>
> Closures, function with a state, OOP, are basically the same thing.
> They just have slightly different perspective, slightly different
> connotation, and defined and implemented differently in different
> langs.
>
> When you formalize them into mathematics, they amount to the same
> thing.
>
> People, stop tech geeking. Get ya heads out of sand. Stop drilling on
> definitions and terminologies, or burying yourself deep inside Common
> Lisp. The originall poster of this thread is perhaps asking about
> terminologies in CL context and i hijacked the thread to discuss the
> concept of closure itself in general. At least i wished you could see
> that.
>
> The Kent Pitman fella is a pest. He is the circular priest. Writes
> long and carefully, and very difficult to deal with. Whatever he
> didn't like, will become the lamb to be put up for slaughter when the
> time comes.
>
> The Rainer fella insists his posting of Common Lisp code as a way to
> put the discussion on firm grounds. What a meritable fellow. Try Emacs
> Lisp Rainer, or Mathemtica. If you have a question on the latter, i
> can help you.
>
> Tim X, shuddap and go do your school work.
>
> Kenny!!!!!! I saw your vid on google. On the beach babbling about the
> wonders of Common Lisp. You crazy!!!!
Thx! I try.
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
·······@gmail.com" <······@gmail.com> writes:
> People, closures is effectively just function using global vars,
> alright?
No, it is not.
That is, unless you remove any meaning to the word "global". See below.
> You want functions to share env? create a naming scheme like
> _contextA_var1, _contextA_var2, ... then functions can share
> _contextA_* vars.
>
> You want 2 different env? have it _contextA_*, _contextB_* ... etc.
(defun make-a-closure (x)
(let ((y x))
(list (lambda () y)
(lambda (v) (setf y v)))))
Y is not a global variable.
There will be as many different variables denoted by Y as calls to MAKE-A-CLOSURE.
Each of these variable is not global, because it cannot be accessed
globally. It can only be accessed by the functions that are in the
scope of the closure (specifically, for Y, the lexical scope of that LET).
> You want nesting? Have it _contextA_ContextA_*...,
> _contextA_ContextB_*..., _contextA_ContextA_ContextA*,
> _contextA_ContextA_ContextB*, ..., etc.
>
> No, the prefix “_” isn't alluding to Python's object whatnot or
> anything. It just any random string as a naming convention so it could
> be programatically identified and hidden from user. (think how you
> would implement closure)
This is exactly what we would like you to do: think about how closures
would be implemented!
> In this way, you have closures, or what closures is supposed to
> achieve in a program, in just about any language.
No. If you speak of just about any language, then just do it! Try to
implement the above make-a-closure function in C and see how you just
cannot use a global variable for Y!
Test your C function with the equivalent in C of:
(mapcar (function make-a-closure)
(COM.INFORMATIMAGO.COMMON-LISP.LIST:IOTA
(progn (princ "Enter an integer: ") (read))))
> Closures, function with a state, OOP, are basically the same thing.
Yes. And object slots just ARE NOT global variables, but quite the
opposite. Therefore enclosed variable are not global variables, CQFD.
Thanks for exposing your own contradictions.
> They just have slightly different perspective, slightly different
> connotation, and defined and implemented differently in different
> langs.
>
> When you formalize them into mathematics, they amount to the same
> thing.
Which is not global variables.
--
__Pascal Bourguignon__
·······@gmail.com" <······@gmail.com> writes:
> People, closures is effectively just function using global vars,
> alright?
No, you just can't emulate closures completley by using global vars,
because your global vars have to be defined at compile time but new
closures may be generated at run time.
The only way to make your statement true, is to rub out all common
meaning of global vars and substitute it's meaning with something like
'my global var is a complex machinery, that may store dynamically an
unbound number of data'.
A closure is, to try a more formal, mathematical definition, an object
consisting of two components: a function body (the code) and an
accompanying environment (just a bunch of data). The important issue
here is that a single function body (= piece of code found in the
sources) may be used to create (unbound) many *different* closures
(each with quite different data), all existing at the same time in
parallel (so just resetting global state before each function call
based on a bound, static number of global variables, is not enough to
simulate this -- you need at least something like a (global)
dictionary and quite some bookkeeping code).
No Common Lisp, even no source code. I hope, now you are satisfied and
you see, you misunderstood the concept.
BTW: I find it really exceptional to reason about programming concepts
and at the same time to declare concrete examples with source code to
be a hindrance in understanding -- every other people I know of see
this quite the other way round: Concrete examples are helpful to
better understand programming concepts. (And in a group like
comp.lang.lisp examples in Lisp came quite naturally, don't you think
so?)
--
Stefan.
Dear Stefan and all,
If you could, put out a snippet of code of closure, in emacs lisp.
I'll show how it is done with global vars.
Common Lisp is fine but i don't know Common Lisp.
------------
For good or bad, i'd like to reiterate here: folks, closures are
effectively just function using global vars. This, is the most clear
statement capturing the heart of closure, and illustrating it in a
background practically all modern computer languages can understand.
It is just one perspective, not the only way. It isn't a correct
description if taken from the perspective of history. It isn't a
sensible description from the perspective of implementation. But from
semantic point of view, with a touch of education and pragmatics, it
is perfect.
what you guys are saying, are technical details. One social way to see
this is that, effectively the closure is used in lisp community only.
Outside, may it be bash, perl, python, javascript, Java, Haskell,
Mathematica, the term is effectively unknown. Not that these languages
doesn't have the power of closure builtin, just that the term is
foreign. Why? Precisely because only the Lisp languages, define or
implement them in particular way, and call it Closure.
Stefan Nobis <······@gmx.de> wrote:
«A closure is, to try a more formal, mathematical definition, an
object consisting of two components: a function body (the code) and an
accompanying environment (just a bunch of data). ...»
Yeah. Now, that accompanying env, can be the global env. One just need
to partition it so as to become several envs with a identification
scheme. One simple to illustrate way, is by tagging id to the var
names. (folks, was this so hard to understand? was this so deep a
concept that required me like 5 painful messages in heavy competition
to finially clarify? Recall, Rainer began, by called me FUD! That's
FEAR, UNCERTAINTY, and DOUUUUUUUBT!!!)
Effectively, a closure is just language feature that allow users to
create subroutines that works as a state machine. Alternatively, a
closure feature that would give a subroutine a paper and pen, where it
can write down values and remember it.
Global vars is one big piece of paper folks. Share!
For a good, fresh, simple, explanation of the semantic essence, of
many jargons and concepts in computing esp those associated with OOP,
see:
What are OOP's Jargons and Complexities
http://xahlee.org/Periodic_dosage_dir/t2/oop.html
Read the above, and you'll come away with a clarity, of the
mathematical essence of many jargons and concepts you hear all day,
like never before.
If nobody can show a snippet of emacs lisp code of closure for me to
tear down, then i demand 3 public posts of this content: Xah Lee is a
beautiful.
PS soliloquy to myself: gosh, i so hate tech geekers. The dumb, fat,
stupid, ugly, common, plebian, asses. Slaving around the world all
day, just to contradict me and pull me down. O, this reminds me,
Friedrich Nietzsche wrote about Master-slave morality. Yeah, the
fucking asses of the mundane. Catch heart attack!!!!!
Xah
···@xahlee.org
∑ http://xahlee.org/
☄
On May 5, 8:01 am, Stefan Nobis <······@gmx.de> wrote:
> ·······@gmail.com" <······@gmail.com> writes:
> > People, closures is effectively just function using global vars,
> > alright?
>
> No, you just can't emulate closures completley by using global vars,
> because your global vars have to be defined at compile time but new
> closures may be generated at run time.
>
> The only way to make your statement true, is to rub out all common
> meaning of global vars and substitute it's meaning with something like
> 'my global var is a complex machinery, that may store dynamically an
> unbound number of data'.
>
> A closure is, to try a more formal, mathematical definition, an object
> consisting of two components: a function body (the code) and an
> accompanying environment (just a bunch of data). The important issue
> here is that a single function body (= piece of code found in the
> sources) may be used to create (unbound) many *different* closures
> (each with quite different data), all existing at the same time in
> parallel (so just resetting global state before each function call
> based on a bound, static number of global variables, is not enough to
> simulate this -- you need at least something like a (global)
> dictionary and quite some bookkeeping code).
>
> No Common Lisp, even no source code. I hope, now you are satisfied and
> you see, you misunderstood the concept.
>
> BTW: I find it really exceptional to reason about programming concepts
> and at the same time to declare concrete examples with source code to
> be a hindrance in understanding -- every other people I know of see
> this quite the other way round: Concrete examples are helpful to
> better understand programming concepts. (And in a group like
> comp.lang.lisp examples in Lisp came quite naturally, don't you think
> so?)
>
> --
> Stefan.
Xah Lee wrote:
> If you could, put out a snippet of code of closure, in
> emacs lisp. I'll show how it is done with global vars.
There are some here, using the CL package's lexical-let
macro:
http://www.delorie.com/gnu/docs/emacs/cl_21.html
--
Aaron
http://arundelo.com/
On Mon, 5 May 2008 20:33:02 -0700 (PDT), ·······@gmail.com"
<······@gmail.com> wrote:
>Dear Stefan and all,
>
>If you could, put out a snippet of code of closure, in emacs lisp.
>I'll show how it is done with global vars.
>
>Common Lisp is fine but i don't know Common Lisp.
>
>------------
>
>For good or bad, i'd like to reiterate here: folks, closures are
>effectively just function using global vars.
You mean "free" variables.
>This, is the most clear
>statement capturing the heart of closure, and illustrating it in a
>background practically all modern computer languages can understand.
>
>It is just one perspective, not the only way. It isn't a correct
>description if taken from the perspective of history. It isn't a
>sensible description from the perspective of implementation. But from
>semantic point of view, with a touch of education and pragmatics, it
>is perfect.
Given that Lisp is the second oldest language, the history of closures
would seem to be on the side of Lisp.
>what you guys are saying, are technical details.
I didn't say anything about implementation details in my responses to
either you or to the OP - I spoke about concepts and semantics. So,
by the way, did Stefan.
I included a small snippet of Lisp in one of my posts simply to have a
example of nested functions to talk about, but my other post was code
free as was Stefan's post.
>One social way to see
>this is that, effectively the closure is used in lisp community only.
>Outside, may it be bash, perl, python, javascript, Java, Haskell,
>Mathematica, the term is effectively unknown. Not that these languages
>doesn't have the power of closure builtin, just that the term is
>foreign. Why? Precisely because only the Lisp languages, define or
>implement them in particular way, and call it Closure.
Closures are well known to the implementors of all the languages you
deigned to list. The fact that users of those languages are ignorant
of the concepts and terminology is not relevant to this discussion ...
Lisp users are not ignorant of them and this discussion is in a Lisp
forum.
And I think most Haskell users know what a closure is ... as well as
most users of ML family languages (ML, SML, Caml, Ocaml, etc.), and of
Scheme, Erlang, Mercury, Oz, etc. [Apologies to anyone whose favorite
FPL I forgot to mention - I don't know them all offhand.]
>Stefan Nobis <······@gmx.de> wrote:
>�A closure is, to try a more formal, mathematical definition, an
>object consisting of two components: a function body (the code) and an
>accompanying environment (just a bunch of data). ...�
>
>Yeah. Now, that accompanying env, can be the global env. One just need
>to partition it so as to become several envs with a identification
>scheme. One simple to illustrate way, is by tagging id to the var
>names. (folks, was this so hard to understand? was this so deep a
>concept that required me like 5 painful messages in heavy competition
>to finially clarify? Recall, Rainer began, by called me FUD! That's
>FEAR, UNCERTAINTY, and DOUUUUUUUBT!!!)
Yes. That is one possible way - not terribly efficient but possible.
But you just complained that _we_ were being technical ... and now
here _you_ are proposing an implementation.
And if you had started with this or a similar explanation which shows
you have some knowledge of environments rather than spouting
innanities about naming conventions, it's likely this thread would not
have developed as it has.
>Effectively, a closure is just language feature that allow users to
>create subroutines that works as a state machine. Alternatively, a
>closure feature that would give a subroutine a paper and pen, where it
>can write down values and remember it.
Now you're confused again. A closure is simply a mechanism that
allows a function to save private state - having a closure does not
create a stateful function.
>Global vars is one big piece of paper folks. Share!
And here you confirm the unique semantics of globals which make them
undesirable for maintaining private state.
>For a good, fresh, simple, explanation of the semantic essence, of
>many jargons and concepts in computing esp those associated with OOP,
>see:
>
> What are OOP's Jargons and Complexities
> http://xahlee.org/Periodic_dosage_dir/t2/oop.html
>
>Read the above, and you'll come away with a clarity, of the
>mathematical essence of many jargons and concepts you hear all day,
>like never before.
>
>If nobody can show a snippet of emacs lisp code of closure for me to
>tear down, then i demand 3 public posts of this content: Xah Lee is a
>beautiful.
>
>PS soliloquy to myself: gosh, i so hate tech geekers. The dumb, fat,
>stupid, ugly, common, plebian, asses. Slaving around the world all
>day, just to contradict me and pull me down. O, this reminds me,
>Friedrich Nietzsche wrote about Master-slave morality. Yeah, the
>fucking asses of the mundane. Catch heart attack!!!!!
>
> Xah
> ···@xahlee.org
>? http://xahlee.org/
>
>?
>
>On May 5, 8:01 am, Stefan Nobis <······@gmx.de> wrote:
>> ·······@gmail.com" <······@gmail.com> writes:
>> > People, closures is effectively just function using global vars,
>> > alright?
>>
>> No, you just can't emulate closures completley by using global vars,
>> because your global vars have to be defined at compile time but new
>> closures may be generated at run time.
>>
>> The only way to make your statement true, is to rub out all common
>> meaning of global vars and substitute it's meaning with something like
>> 'my global var is a complex machinery, that may store dynamically an
>> unbound number of data'.
>>
>> A closure is, to try a more formal, mathematical definition, an object
>> consisting of two components: a function body (the code) and an
>> accompanying environment (just a bunch of data). The important issue
>> here is that a single function body (= piece of code found in the
>> sources) may be used to create (unbound) many *different* closures
>> (each with quite different data), all existing at the same time in
>> parallel (so just resetting global state before each function call
>> based on a bound, static number of global variables, is not enough to
>> simulate this -- you need at least something like a (global)
>> dictionary and quite some bookkeeping code).
>>
>> No Common Lisp, even no source code. I hope, now you are satisfied and
>> you see, you misunderstood the concept.
>>
>> BTW: I find it really exceptional to reason about programming concepts
>> and at the same time to declare concrete examples with source code to
>> be a hindrance in understanding -- every other people I know of see
>> this quite the other way round: Concrete examples are helpful to
>> better understand programming concepts. (And in a group like
>> comp.lang.lisp examples in Lisp came quite naturally, don't you think
>> so?)
>>
>> --
>> Stefan.
George
--
for email reply remove "/" from address
·······@gmail.com" <······@gmail.com> writes:
> Dear Stefan and all,
>
> If you could, put out a snippet of code of closure, in emacs lisp.
> I'll show how it is done with global vars.
emacs lisp has no closure.
lexical-let simulate closures in emacs lisp, but not using global
variables! It does so by creating symbols on the heap. lexical-let
could have just used structures to do the same.
Instead of:
(macroexpand '(lexical-let ((x n)) (lambda (y) (+ x y))))
-->
(let ((--cl-x-- (make-symbol "--x--")))
(setf (symbol-value --cl-x--) n)
(list (quote lambda) (quote (&rest --cl-rest--))
(list (quote apply) (function (lambda (G84404 y) (+ (symbol-value G84404) y))) (list (quote quote) --cl-x--) (quote --cl-rest--))))
we could have:
-->
(defstruct variable value)
(let ((--cl-x-- (make-variable)))
(setf (variable-value --cl-x--) n)
(list (quote lambda) (quote (&rest --cl-rest--))
(list (quote apply) (function (lambda (G84404 y) (+ (variable-value G84404) y))) (list (quote quote) --cl-x--) (quote --cl-rest--))))
Which shows that there's nothing related to global variable in there.
These symbols just cannot name global variables, because if they did,
you'd get collisions and conflate closure variables into a single
global variable!
if --cl-x-- named a global variable, this would be wrong:
(list
(lexical-let ((x 1)) (lambda (y) (+ x y)))
(lexical-let ((x 2)) (lambda (y) (+ x y))))
since both closure in the list would add 2 to their argument!
To implement closures you just cannot use global variables.
> Common Lisp is fine but i don't know Common Lisp.
Perhaps you should learn it...
> For good or bad, i'd like to reiterate here: folks, closures are
> effectively just function using global vars. This, is the most clear
> statement capturing the heart of closure, and illustrating it in a
> background practically all modern computer languages can understand.
You just don't know what a closure is, and you just don't know what a
global variable is either. This is frightening.
> What you guys are saying, are technical details. One social way to see
> this is that, effectively the closure is used in lisp community only.
> Outside, may it be bash, perl, python, javascript, Java, Haskell,
> Mathematica, the term is effectively unknown. Not that these languages
> doesn't have the power of closure builtin, just that the term is
> foreign. Why? Precisely because only the Lisp languages, define or
> implement them in particular way, and call it Closure.
No. That's because Common Lisp talks about real hard physical fact of
life, while the other programming languages are toys from DisneyLand.
Saying that closures are done with globals, is like saying that Mickey
and Minie never had sex (or actually like saying that Mickey's brother
or sister never had sex despite of Mickey's nephews). It's possible,
but only in DisneyLand.
> Stefan Nobis <······@gmx.de> wrote:
> �A closure is, to try a more formal, mathematical definition, an
> object consisting of two components: a function body (the code) and an
> accompanying environment (just a bunch of data). ...�
>
> Yeah. Now, that accompanying env, can be the global env. One just need
> to partition it so as to become several envs with a identification
> scheme. One simple to illustrate way, is by tagging id to the var
> names. (folks, was this so hard to understand? was this so deep a
> concept that required me like 5 painful messages in heavy competition
> to finially clarify? Recall, Rainer began, by called me FUD! That's
> FEAR, UNCERTAINTY, and DOUUUUUUUBT!!!)
And that's where you don't have global variables anymore!
Once Mickey has sex, it's not DisneyLand anymore! It's real life.
> What are OOP's Jargons and Complexities
> http://xahlee.org/Periodic_dosage_dir/t2/oop.html
Yes, we know that you prefer Disney literature to scientific papers.
Good luck dealing with the world with these ideas!
--
__Pascal Bourguignon__
·······@gmail.com" <······@gmail.com> wrote:
> Dear Stefan and all,
>
> If you could, put out a snippet of code of closure, in emacs lisp.
> I'll show how it is done with global vars.
Emacs Lisp is probably the worst Lisp dialect ever. You shouldn't try
to learn Lisp from Emacs Lisp. To answer your question: have a look at
the macro lexical-let in cl-macs.el.
> For good or bad, i'd like to reiterate here: folks, closures are
> effectively just function using global vars.
Again, that is meaningless. Define "using". Define "global" (seems
quite different from what a global var actually is).
--
5th European Lisp Workshop at ECOOP 2008, July 7: http://elw.bknr.net/2008/
Didier Verna, ······@lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (0)1 44 08 01 85
94276 Le Kremlin-Bic�tre, France Fax.+33 (0)1 53 14 59 22 ······@xemacs.org
On May 6, 3:57 am, Didier Verna <······@xemacs.org> wrote:
> ·······@gmail.com" <······@gmail.com> wrote:
> > Dear Stefan and all,
>
> > If you could, put out a snippet of code of closure, in emacs lisp.
> > I'll show how it is done with global vars.
>
> Emacs Lisp is probably the worst Lisp dialect ever.
On the contrary, Emacs Lisp (Elisp) works very well for its
constitutents who use the dialect as it was intended - primarily to
customize and extend "the extensible, customizable, self-documenting,
real-time display editor" Emacs.
Xah, Elisp is not a Common Lisp, so one cannot hope to master Common
Lisp using Elisp as the programming tool. Elisp uses dynamic and not
lexical scope, and has no obect system.
The fundamental goal of cllers is mastery of Common Lisp. Discussions
of a more philosophical content may be interesting from time to time,
but are tangential to the real effort of honing skills in Common
Lisp.To do the latter one has to translate from philosophical
abstractions to real code. The problem night be much like expecting to
master the piano while confining practice to scales representing the
theory of musical intervals (http://xahlee.org/UnixResource_dir/writ/
piano_scale.html). At some point one has to practice compositions -
musical code - in order to learn. What you need to do is download a
reasonable implementation of Common Lisp, get a good text or two and
write code, code, code.
One can see that you are smart, but referring to cllers as "morons",
or using the "frack" word indiscriminately, is not likely to
encourage positive responses. Good luck.
agt
viper-2 <········@mail.infochan.com> wrote:
> On May 6, 3:57 am, Didier Verna <······@xemacs.org> wrote:
>>
>> Emacs Lisp is probably the worst Lisp dialect ever.
>
> On the contrary, Emacs Lisp (Elisp) works very well for its
> constitutents who use the dialect as it was intended - primarily to
> customize and extend "the extensible, customizable, self-documenting,
> real-time display editor" Emacs.
You have got to be kidding me. I don't see how being dynamically
scoped by default helps you in any way (even in a self-blah-blah editor
in which user options could simply be defined in terms of CL's
defparameter). I don't see how not having lexical scope helps you in any
way either.
On the other hand, I (among others) maintain XEmacs, Gnus, BBDB, and a
few packages of my own, and I can tell you how I wish Emacs Lisp had
CLOS, or simply were just Common-Lisp in the first place.
BTW, what exactly do you mean by "customize and extend [...]" ? Today,
XEmacs has 30% (~ 150000 lines) of its code base written in elisp; Gnus
alone amounts to 140000 lines, and I'm not even speaking of XEmacs'SUMO
tarballs (the whole external libraries shipped as packages). I wouldn't
call elisp an "extension language" anymore.
--
5th European Lisp Workshop at ECOOP 2008, July 7: http://elw.bknr.net/2008/
Didier Verna, ······@lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (0)1 44 08 01 85
94276 Le Kremlin-Bic�tre, France Fax.+33 (0)1 53 14 59 22 ······@xemacs.org
On May 6, 12:14 pm, Didier Verna <······@xemacs.org> wrote:
> viper-2 <········@mail.infochan.com> wrote:
> > On May 6, 3:57 am, Didier Verna <······@xemacs.org> wrote:
>
>
> You have got to be kidding me. I don't see how being dynamically
> scoped by default helps you in any way (even in a self-blah-blah editor
> in which user options could simply be defined in terms of CL's
> defparameter). I don't see how not having lexical scope helps you in any
> way either.
Remember that Elisp (a variant of MacLisp) preceded Common Lisp, hence
no CLOS. The reasons for the use of dynamic scoping have to do with
the design decisions RMS made at the time he decided to rewrite his
TECO based EMACS. I believe (but I could be wrong here) that at the
time, Steele's and Sussman's Scheme project performed poorly with
lexical scoping. Dynamic scoping was thought to be more efficient; see
http://www.gnu.org/software/emacs/emacs-paper.html#SEC17.
>
> BTW, what exactly do you mean by "customize and extend [...]" ?
I quoted this from the GNU EMACS Manual http://www.gnu.org/software/emacs/manual/html_mono/emacs.html.
That is how EMACS is commonly referred to by its devotees. Maybe
someone else would clue you in? I'd like to go into more detail, but
I'm completely tied up right now with my law project - the ICC and
suppression of a complaint ( reference Nos. OTP-CR-313/04 and 113-07/
VZ/OO) against the University of Aberdeen (Scotland) for the crime of
apartheid. :-(
I would much prefer to spend my time with mathematics, engineering,
and Lisp.
agt
In article
<····································@a70g2000hsh.googlegroups.com>,
viper-2 <········@mail.infochan.com> wrote:
> On May 6, 12:14 pm, Didier Verna <······@xemacs.org> wrote:
> > viper-2 <········@mail.infochan.com> wrote:
> > > On May 6, 3:57 am, Didier Verna <······@xemacs.org> wrote:
> >
> >
> > You have got to be kidding me. I don't see how being dynamically
> > scoped by default helps you in any way (even in a self-blah-blah editor
> > in which user options could simply be defined in terms of CL's
> > defparameter). I don't see how not having lexical scope helps you in any
> > way either.
>
> Remember that Elisp (a variant of MacLisp) preceded Common Lisp, hence
> no CLOS.
Well, RMS worked on the Lisp Machine. He even wrote manuals for it.
He wrote for example the Zmail manual
and co-wrote the Window System Manual. He knew the system very well.
Including Flavors, the object system. He himself wrote an
object-system before there was Flavors. Lisp Machine Lisp was
dynamically scoped with some support for closures.
There was more experience with dynamically scoped Lisps at that time.
> The reasons for the use of dynamic scoping have to do with
> the design decisions RMS made at the time he decided to rewrite his
> TECO based EMACS. I believe (but I could be wrong here) that at the
> time, Steele's and Sussman's Scheme project performed poorly with
> lexical scoping. Dynamic scoping was thought to be more efficient; see
> http://www.gnu.org/software/emacs/emacs-paper.html#SEC17.
Well, the language Elisp could have been changed - if lexical scope
or an object system had been important to the language users.
> >
> > BTW, what exactly do you mean by "customize and extend [...]" ?
>
> I quoted this from the GNU EMACS Manual http://www.gnu.org/software/emacs/manual/html_mono/emacs.html.
>
> That is how EMACS is commonly referred to by its devotees. Maybe
> someone else would clue you in? I'd like to go into more detail, but
> I'm completely tied up right now with my law project - the ICC and
> suppression of a complaint ( reference Nos. OTP-CR-313/04 and 113-07/
> VZ/OO) against the University of Aberdeen (Scotland) for the crime of
> apartheid. :-(
>
> I would much prefer to spend my time with mathematics, engineering,
> and Lisp.
>
> agt
--
http://lispm.dyndns.org/
On May 6, 3:00 pm, Rainer Joswig <······@lisp.de> wrote:
> In article
> <····································@a70g2000hsh.googlegroups.com>,
> Well, RMS worked on the Lisp Machine. He even wrote manuals for it.
> He wrote for example the Zmail manual
> and co-wrote the Window System Manual. He knew the system very well.
> Including Flavors, the object system. He himself wrote an
> object-system before there was Flavors. Lisp Machine Lisp was
> dynamically scoped with some support for closures.
> There was more experience with dynamically scoped Lisps at that time.
>
Hmmm, thank you Rainer; that was informative. I didn't realize that
RMS had written an object system. I must remember to refer to you when
I'm looking for historical tidbits.
agt
In article
<····································@m45g2000hsb.googlegroups.com>,
viper-2 <········@mail.infochan.com> wrote:
> On May 6, 3:00 pm, Rainer Joswig <······@lisp.de> wrote:
> > In article
> > <····································@a70g2000hsh.googlegroups.com>,
>
> > Well, RMS worked on the Lisp Machine. He even wrote manuals for it.
> > He wrote for example the Zmail manual
> > and co-wrote the Window System Manual. He knew the system very well.
> > Including Flavors, the object system. He himself wrote an
> > object-system before there was Flavors. Lisp Machine Lisp was
> > dynamically scoped with some support for closures.
> > There was more experience with dynamically scoped Lisps at that time.
> >
>
> Hmmm, thank you Rainer; that was informative. I didn't realize that
> RMS had written an object system. I must remember to refer to you when
> I'm looking for historical tidbits.
>
> agt
Well, you have to read for example the mentioned
Lisp Machine Window System Manual (available as PDF).
On page 2 there is a 'Note from Richard Stallman',
where he writes in what is clearly his style:
"The current implementation of the window system is based on
flavors, and was designed and implemented primarily by Howard
Cannon and Mike McMahon during 1980. It replaced an
earlier version implemented by me, which was based on
Smalltalk-like classes. The newer system is generally an
improvement, but as Howard Cannon steadfastly refused
to discuss the design with me I must decline responsibility
for such counterintuitive aspects as the definition of
exposure."
--
http://lispm.dyndns.org/
On May 6, 4:00 pm, Rainer Joswig <······@lisp.de> wrote:
> In article
> <····································@m45g2000hsb.googlegroups.com>,
>
> Well, you have to read for example the mentioned
> Lisp Machine Window System Manual (available as PDF).
> On page 2 there is a 'Note from Richard Stallman',
> where he writes in what is clearly his style:
>
> "The current implementation of the window system is based on
> flavors, and was designed and implemented primarily by Howard
> Cannon and Mike McMahon during 1980. It replaced an
> earlier version implemented by me, which was based on
> Smalltalk-like classes. The newer system is generally an
> improvement, but as Howard Cannon steadfastly refused
> to discuss the design with me I must decline responsibility
> for such counterintuitive aspects as the definition of
> exposure."
Noted. BTW Rainer, you have nice name.:-)
agt
On May 6, 3:00 pm, Rainer Joswig <······@lisp.de> wrote:
> In article
> <····································@a70g2000hsh.googlegroups.com>,
>
> viper-2 <········@mail.infochan.com> wrote:
> > On May 6, 12:14 pm, Didier Verna <······@xemacs.org> wrote:
> > > viper-2 <········@mail.infochan.com> wrote:
> > > > On May 6, 3:57 am, Didier Verna <······@xemacs.org> wrote:
>
> > > You have got to be kidding me. I don't see how being dynamically
> > > scoped by default helps you in any way (even in a self-blah-blah editor
> > > in which user options could simply be defined in terms of CL's
> > > defparameter). I don't see how not having lexical scope helps you in any
> > > way either.
>
> > Remember that Elisp (a variant of MacLisp) preceded Common Lisp, hence
> > no CLOS.
>
> Well, RMS worked on the Lisp Machine. He even wrote manuals for it.
> He wrote for example the Zmail manual
> and co-wrote the Window System Manual. He knew the system very well.
> Including Flavors, the object system. He himself wrote an
> object-system before there was Flavors. Lisp Machine Lisp was
> dynamically scoped with some support for closures.
> There was more experience with dynamically scoped Lisps at that time.
>
> > The reasons for the use of dynamic scoping have to do with
> > the design decisions RMS made at the time he decided to rewrite his
> > TECO based EMACS. I believe (but I could be wrong here) that at the
> > time, Steele's and Sussman's Scheme project performed poorly with
> > lexical scoping. Dynamic scoping was thought to be more efficient; see
> >http://www.gnu.org/software/emacs/emacs-paper.html#SEC17.
>
> Well, the language Elisp could have been changed - if lexical scope
> or an object system had been important to the language users.
It seems that I got the chronology wrong. RMS wrote EMACS Lisp after
he had already implemented Common Lisp for the Lisp Machine. His
design was constrained by physical limitations of that time. He just
emailed to say this:
| I designed Emacs Lisp in 1984. I had already
| implemented Common Lisp for the MIT Lisp
| Machine and I did not like it much. Also, it was
| too big. In 1984 I had to simplify Emacs Lisp
| very much to make GNU Emacs fit in the
| memory spaces that were available. That is
| why the only looping construct was `while', and
| the only list mapping function was `mapcar'.
agt
In article
<····································@b1g2000hsg.googlegroups.com>,
viper-2 <········@mail.infochan.com> wrote:
> On May 6, 3:00 pm, Rainer Joswig <······@lisp.de> wrote:
> > In article
> > <····································@a70g2000hsh.googlegroups.com>,
> >
> > viper-2 <········@mail.infochan.com> wrote:
> > > On May 6, 12:14 pm, Didier Verna <······@xemacs.org> wrote:
> > > > viper-2 <········@mail.infochan.com> wrote:
> > > > > On May 6, 3:57 am, Didier Verna <······@xemacs.org> wrote:
> >
> > > > You have got to be kidding me. I don't see how being dynamically
> > > > scoped by default helps you in any way (even in a self-blah-blah editor
> > > > in which user options could simply be defined in terms of CL's
> > > > defparameter). I don't see how not having lexical scope helps you in any
> > > > way either.
> >
> > > Remember that Elisp (a variant of MacLisp) preceded Common Lisp, hence
> > > no CLOS.
> >
> > Well, RMS worked on the Lisp Machine. He even wrote manuals for it.
> > He wrote for example the Zmail manual
> > and co-wrote the Window System Manual. He knew the system very well.
> > Including Flavors, the object system. He himself wrote an
> > object-system before there was Flavors. Lisp Machine Lisp was
> > dynamically scoped with some support for closures.
> > There was more experience with dynamically scoped Lisps at that time.
> >
> > > The reasons for the use of dynamic scoping have to do with
> > > the design decisions RMS made at the time he decided to rewrite his
> > > TECO based EMACS. I believe (but I could be wrong here) that at the
> > > time, Steele's and Sussman's Scheme project performed poorly with
> > > lexical scoping. Dynamic scoping was thought to be more efficient; see
> > >http://www.gnu.org/software/emacs/emacs-paper.html#SEC17.
> >
> > Well, the language Elisp could have been changed - if lexical scope
> > or an object system had been important to the language users.
>
> It seems that I got the chronology wrong. RMS wrote EMACS Lisp after
> he had already implemented Common Lisp for the Lisp Machine. His
> design was constrained by physical limitations of that time. He just
> emailed to say this:
>
>
> | I designed Emacs Lisp in 1984. I had already
> | implemented Common Lisp for the MIT Lisp
> | Machine and I did not like it much. Also, it was
> | too big. In 1984 I had to simplify Emacs Lisp
> | very much to make GNU Emacs fit in the
> | memory spaces that were available. That is
> | why the only looping construct was `while', and
> | the only list mapping function was `mapcar'.
>
>
> agt
Memory WAS tiny then. The Mac of 1984 had 128kbyte RAM.
The Apple Lisa from 1983 had 1 MB RAM.
'Macintosh Allegro CL' by Coral from 1987 wanted a Mac with 1 MB RAM!
HUGE UGLY BLOATED COMMON LISP!!!
Then the bloat got out of control! Imagine, MCL 2.0 demanded a Mac
with a minimum of 4MB RAM and 6 MB disk!!!
;-)
--
http://lispm.dyndns.org/
viper-2 <········@mail.infochan.com> wrote:
> Remember that Elisp (a variant of MacLisp) preceded Common Lisp, hence
> no CLOS. [...]
I know all that. History doesn't change the fact that elisp is a
really poor dialect of Lisp.
>> BTW, what exactly do you mean by "customize and extend [...]" ?
>
> I quoted this from the GNU EMACS Manual
> http://www.gnu.org/software/emacs/manual/html_mono/emacs.html.
>
> That is how EMACS is commonly referred to by its devotees. Maybe
> someone else would clue you in?
Ha ha :-) Like I said, for (most) people thinking that "customizing
and extending" their favorite editor merely boils down to hacking their
.emacs, yes elisp is probably fine. elisp is *not* fine for writing 30%
of the program itself, or a general purpose mailer/newser...
--
5th European Lisp Workshop at ECOOP 2008, July 7: http://elw.bknr.net/2008/
Didier Verna, ······@lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (0)1 44 08 01 85
94276 Le Kremlin-Bic�tre, France Fax.+33 (0)1 53 14 59 22 ······@xemacs.org
Didier Verna <······@lrde.epita.fr> writes:
> viper-2 <········@mail.infochan.com> wrote:
>
>> Remember that Elisp (a variant of MacLisp) preceded Common Lisp, hence
>> no CLOS. [...]
>
> I know all that. History doesn't change the fact that elisp is a
> really poor dialect of Lisp.
>
>
>>> BTW, what exactly do you mean by "customize and extend [...]" ?
>>
>> I quoted this from the GNU EMACS Manual
>> http://www.gnu.org/software/emacs/manual/html_mono/emacs.html.
>>
>> That is how EMACS is commonly referred to by its devotees. Maybe
>> someone else would clue you in?
>
> Ha ha :-) Like I said, for (most) people thinking that "customizing
> and extending" their favorite editor merely boils down to hacking their
> .emacs, yes elisp is probably fine. elisp is *not* fine for writing 30%
> of the program itself, or a general purpose mailer/newser...
In the case of GNU emacs, lisp sources represent 75% of the lines, 78%
of the characters, (taking into account only .el, .h and .c files).
[···@simias emacs-22.1]$ find . -name \*.\[hc] -exec cat {} \; | wc ; find . -name \*.el -exec cat {} \; | wc
396223 1509839 11483825
1163546 4639410 41193794
And of course, this is without considering the add-ons.
[···@simias emacs-22.1]$ cd /usr/share/emacs/site-lisp/
[···@simias site-lisp]$ find . -name \*.\[hc] -exec cat {} \; | wc ; find . -name \*.el -exec cat {} \; | wc
210 566 3823
1315561 5358721 49378935
A fully loaded GNU emacs image will come from at least 89% of emacs lisp
source characters.
And yes, this include several MUAs entirely written in emacs lisp, so
if it's not fine to do that, at least it doesn't discourrage emacs
lisp programmers...
--
__Pascal Bourguignon__
···@informatimago.com (Pascal J. Bourguignon) wrote:
> And yes, this include several MUAs entirely written in emacs lisp, so
> if it's not fine to do that, at least it doesn't discourrage emacs
> lisp programmers...
Right :-) You can always knock in a nail with a screw driver. You just
wish you had a hammer ;-)
But to be really fair, once you get a hammer, it doesn't mean you know
how to use it properly. So part of the problem we have today is also due
to extremely bad design and ugly code in most elisp lines out there.
So on the one hand, we have elisp code, mostly a collection of crappy
hacks on top of each other, but it works... and I'm really wondering, if
a standard elisp object system had existed in the first place, would the
original programmers have been skilled enough to use it and design their
stuff properly ?
On the other hand, we have XEmacs code base, which is very well designed
and abstracted, OO actually[1], but it is written in C with a bunch of ugly
macrology on top because it is rather hard to object-orient plain C code...
Life is hard :-)
Footnotes:
[1] That's the Second Big XEmacs Existential Question. I wish the
codebase were rewritten in C++, but the Schemers "object" to that (ha
ha, didn't actually mean it to turn out as a joke :-)
--
5th European Lisp Workshop at ECOOP 2008, July 7: http://elw.bknr.net/2008/
Didier Verna, ······@lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (0)1 44 08 01 85
94276 Le Kremlin-Bic�tre, France Fax.+33 (0)1 53 14 59 22 ······@xemacs.org
P� Wed, 07 May 2008 10:01:58 +0200, skrev Didier Verna
<······@lrde.epita.fr>:
> ···@informatimago.com (Pascal J. Bourguignon) wrote:
>
>> And yes, this include several MUAs entirely written in emacs lisp, so
>> if it's not fine to do that, at least it doesn't discourrage emacs
>> lisp programmers...
>
> Right :-) You can always knock in a nail with a screw driver. You just
> wish you had a hammer ;-)
>
> But to be really fair, once you get a hammer, it doesn't mean you know
> how to use it properly. So part of the problem we have today is also due
> to extremely bad design and ugly code in most elisp lines out there.
>
> So on the one hand, we have elisp code, mostly a collection of crappy
> hacks on top of each other, but it works... and I'm really wondering, if
> a standard elisp object system had existed in the first place, would the
> original programmers have been skilled enough to use it and design their
> stuff properly ?
>
> On the other hand, we have XEmacs code base, which is very well designed
> and abstracted, OO actually[1], but it is written in C with a bunch of
> ugly
> macrology on top because it is rather hard to object-orient plain C
> code...
>
erm. emacs is a evolved system that worked the whole time while they added
code. If you had 'designed' it with the current features I doubt if it
would ever have worked in the first place. Another question is if OO
design would have made it 'better' or just more 'familiar'.
--------------
John Thingstad
"John Thingstad" <·······@online.no> wrote:
> emacs is a evolved system that worked the whole time while they added
> code. If you had 'designed' it with the current features I doubt if it
> would ever have worked in the first place.
If not in the first place, emacs lisp code could have evolved if elisp
itself had; but that didn't really happen. At some point (I mean right
now), perhaps starting from scratch again would be better than
refactoring.
> Another question is if OO design would have made it 'better' or just
> more 'familiar'.
Right. Not all parts would necessarily benefit from object
orientation, but some definitely would. What's more (at least in the
case of XEmacs), some parts already *are* object-oriented; just not in
an OO language which is a real PITA. Refactoring those parts with a
more modern tool underneath would not be difficult, because the design
is already there.
--
5th European Lisp Workshop at ECOOP 2008, July 7: http://elw.bknr.net/2008/
Didier Verna, ······@lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (0)1 44 08 01 85
94276 Le Kremlin-Bic�tre, France Fax.+33 (0)1 53 14 59 22 ······@xemacs.org
Didier Verna <······@lrde.epita.fr> writes:
> "John Thingstad" <·······@online.no> wrote:
>
>> emacs is a evolved system that worked the whole time while they added
>> code. If you had 'designed' it with the current features I doubt if it
>> would ever have worked in the first place.
>
> If not in the first place, emacs lisp code could have evolved if elisp
> itself had; but that didn't really happen. At some point (I mean right
> now), perhaps starting from scratch again would be better than
> refactoring.
>
>
>> Another question is if OO design would have made it 'better' or just
>> more 'familiar'.
>
> Right. Not all parts would necessarily benefit from object
> orientation, but some definitely would. What's more (at least in the
> case of XEmacs), some parts already *are* object-oriented; just not in
> an OO language which is a real PITA. Refactoring those parts with a
> more modern tool underneath would not be difficult, because the design
> is already there.
I don't see what's the problem. Lisp is a programmable programming
language. There's nothing easier than to define an OO system in Lisp.
Do Xemacs hackers need to learn about defmacro?
If you already have implemented some OO patterns manually, it would be
quite easy to just define the macros to formalize these patterns, and
progressively replace manual patterns with macro calls. When it'll be
all done, you will be able to change the implementation of these
macros if needed.
--
__Pascal Bourguignon__
···@informatimago.com (Pascal J. Bourguignon) wrote:
>> Right. Not all parts would necessarily benefit from object
>> orientation, but some definitely would. What's more (at least in the
>> case of XEmacs), some parts already *are* object-oriented; just not
>> in an OO language which is a real PITA. Refactoring those parts with
>> a more modern tool underneath would not be difficult, because the
>> design is already there.
Note that here I was talking about the C layer mostly.
> Do Xemacs hackers need to learn about defmacro?
[ That's XEmacs ] defwhat ?
--
5th European Lisp Workshop at ECOOP 2008, July 7: http://elw.bknr.net/2008/
Didier Verna, ······@lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (0)1 44 08 01 85
94276 Le Kremlin-Bic�tre, France Fax.+33 (0)1 53 14 59 22 ······@xemacs.org
Didier Verna <······@lrde.epita.fr> writes:
> ···@informatimago.com (Pascal J. Bourguignon) wrote:
>
>>> Right. Not all parts would necessarily benefit from object
>>> orientation, but some definitely would. What's more (at least in the
>>> case of XEmacs), some parts already *are* object-oriented; just not
>>> in an OO language which is a real PITA. Refactoring those parts with
>>> a more modern tool underneath would not be difficult, because the
>>> design is already there.
>
> Note that here I was talking about the C layer mostly.
Ah, sorry, I didn't realize. Indeed, if XEmacs is written at 85% in C,
it would be hard to do anything with it...
>> Do Xemacs hackers need to learn about defmacro?
>
> [ That's XEmacs ] defwhat ?
However, there are also object systems written for C.
Objective-C is an obvious one.
COS another with some influences from Objective-C and some from CLOS:
http://sourceforge.net/projects/cos
Good luck ;-)
--
__Pascal Bourguignon__
···@informatimago.com (Pascal J. Bourguignon) wrote:
> However, there are also object systems written for C.
>
> Objective-C is an obvious one.
>
> COS another with some influences from Objective-C and some from CLOS:
> http://sourceforge.net/projects/cos
Didn't know about that. Puzzling.
We digress, but I remember reading a book from a guy claiming that he
didn't have to use C++ because he could do OO in C, and the book was
about proving that by constructing a set of CPP macros to implement the
object layer. That reading was... well...
I wish I remembered the name.
--
5th European Lisp Workshop at ECOOP 2008, July 7: http://elw.bknr.net/2008/
Didier Verna, ······@lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (0)1 44 08 01 85
94276 Le Kremlin-Bic�tre, France Fax.+33 (0)1 53 14 59 22 ······@xemacs.org
In article <···············@uzeb.lrde.epita.fr>,
Didier Verna <······@lrde.epita.fr> wrote:
> ···@informatimago.com (Pascal J. Bourguignon) wrote:
>
> > However, there are also object systems written for C.
> >
> > Objective-C is an obvious one.
> >
> > COS another with some influences from Objective-C and some from CLOS:
> > http://sourceforge.net/projects/cos
>
> Didn't know about that. Puzzling.
Dynace
http://algorithms.us/software/dynace/intro.html
"Dynace is a preprocessor, include files and a library which
extends the C and C++ languages with advanced object
oriented capabilities, automatic garbage collection
and multiple threads. Dynace is designed to solve
many of the problems associated with C++ while being
easier to learn and containing more flexable
object oriented facilities. Dynace is able to add
facilities previously only available in languages
such as Smalltalk and CLOS without all the overhead
normally associated with those environments."
>
> We digress, but I remember reading a book from a guy claiming that he
> didn't have to use C++ because he could do OO in C, and the book was
> about proving that by constructing a set of CPP macros to implement the
> object layer. That reading was... well...
>
> I wish I remembered the name.
--
http://lispm.dyndns.org/
Rainer Joswig <······@lisp.de> writes:
> In article <···············@uzeb.lrde.epita.fr>,
> Didier Verna <······@lrde.epita.fr> wrote:
>
>> ···@informatimago.com (Pascal J. Bourguignon) wrote:
>>
>> > However, there are also object systems written for C.
>> >
>> > Objective-C is an obvious one.
>> >
>> > COS another with some influences from Objective-C and some from CLOS:
>> > http://sourceforge.net/projects/cos
>>
>> Didn't know about that. Puzzling.
>
> Dynace
> http://algorithms.us/software/dynace/intro.html
> "Dynace is a preprocessor, include files and a library which
> extends the C and C++ languages with advanced object
> oriented capabilities, automatic garbage collection
> and multiple threads. Dynace is designed to solve
> many of the problems associated with C++ while being
> easier to learn and containing more flexable
> object oriented facilities. Dynace is able to add
> facilities previously only available in languages
> such as Smalltalk and CLOS without all the overhead
> normally associated with those environments."
Well, right. ECL and gcl are nice C preprocessors too. They even
include a good object system, named CLOS I believe... ;-)
--
__Pascal Bourguignon__
viper-2 <········@mail.infochan.com> writes:
> On May 6, 12:14 pm, Didier Verna <······@xemacs.org> wrote:
>> viper-2 <········@mail.infochan.com> wrote:
>> > On May 6, 3:57 am, Didier Verna <······@xemacs.org> wrote:
>>
>>
>> You have got to be kidding me. I don't see how being dynamically
>> scoped by default helps you in any way (even in a self-blah-blah editor
>> in which user options could simply be defined in terms of CL's
>> defparameter). I don't see how not having lexical scope helps you in any
>> way either.
>
> Remember that Elisp (a variant of MacLisp) preceded Common Lisp, hence
> no CLOS.
However, there are libraries. For example, eieio implements CLOS
http://cedet.sourceforge.net/eieio.shtml
(with some differences, of course:
http://cedet.sourceforge.net/info/eieio.html#SEC6
)
--
__Pascal Bourguignon__
···@informatimago.com (Pascal J. Bourguignon) wrote:
> viper-2 <········@mail.infochan.com> writes:
>>
>> Remember that Elisp (a variant of MacLisp) preceded Common Lisp,
>> hence no CLOS.
>
> However, there are libraries. For example, eieio implements CLOS
> http://cedet.sourceforge.net/eieio.shtml
Yup. I don't remember exactly when eieio came out, but the point is,
given the amount of already existing elisp code, both in the editors
themselves and in external libraries, the time and energy required to
rewrite the whole stuff in a better way would be tremendous...
Not to mention that every time I express the wish to rewrite XEmacs in
CL, some of the other guys jump at me and express their wish to rewrite
it in Scheme ;-)
--
5th European Lisp Workshop at ECOOP 2008, July 7: http://elw.bknr.net/2008/
Didier Verna, ······@lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (0)1 44 08 01 85
94276 Le Kremlin-Bic�tre, France Fax.+33 (0)1 53 14 59 22 ······@xemacs.org
On May 6, 12:57 am, Didier Verna <······@xemacs.org> wrote:
«Emacs Lisp is probably the worst Lisp dialect ever. You shouldn't try
to learn Lisp from Emacs Lisp...»
Dear Didier,
i started to read comp.lang.lisp since 1998 or 1999. I don't actually
read it that much, but usually in periodic bursts, perhaps few times a
year, few weeks per bout, i'd come in and read a lot, sometimes post
too.
Thru the years, i have come to know quite a few regulars. For example,
Erik Naggum, Kent Pitman, Kenny, Rainer, at least 3 Christophers, Tims
Bradshaw, 2 Pascals, Mark Tarver, Brian Harvey, William Clinger, Dorai
Sitaram, Richard Fateman, Duane Rettig, Richard Gabriel, David
Lamkins, Barry Margolin, john harrop, Coby Beck, Joe Marshall, Nils
Goesche... and many more (won't be bothering to put full effort to
make a listful here... )
Some have come and gone, as is the ways of newsgroup and life. Not
that i love them all. Some i read, some i swear off, many i have
exchanged missives. In general, it was fun. I wish them well. When
next time i have nothing to do i shall write a brief of Who's Who of
comp.lang.lisp, detailing each's deeds, persona, trivia. Certainly, it
can function as a bible of who knows what, who's more fluffy, who's
fun, who's serious, who's got nothing to do all day, who's man of few
words.
however, you seem to have crawled out of the woodwork into my
awareness today. May i ask, your credential please?
As a way of introduction of myself, perhaps i can show you this essay
of mine:
• The Concepts and Confusions of Prefix, Infix, Postfix and Fully
Functional Notations
http://xahlee.org/UnixResource_dir/writ/notations.html
Regarding your contemplation and regurgitation on the issues of
modernization of emacs lisp, and or emacs vs xemacs, please you
peruse:
• Modernization of Emacs Lisp
http://xahlee.org/emacs/modernization_of_elisp.html
• My Experience of Emacs vs Xemacs
http://xahlee.org/emacs/emacs_vs_xemacs.html
Regarding your patronizing concern and officious advice of learning
Common Lisp, you might want to be acquainted with the fact i have no
interest in learning Common Lisp whatsoever.
Thank you.
Xah
···@xahlee.org
∑ http://xahlee.org/
☄
From: Robert Maas, http://tinyurl.com/uh3t
Subject: Re: A question (confusion) about closure
Date:
Message-ID: <rem-2008may08-004@yahoo.com>
> From: ·······@gmail.com" <······@gmail.com>
> sometimes something so obvious and clear to me but can't get
> other programers to see.
Or you might actually be mistaken, and too stubborn to admit your
mistake. You wouldn't want to get a reputation like Archemedes
Plutonium or JSH or Brad Guth, would you?
> Robert Maas came in too. So silly.
Not silly at all. I have a valid complaint with your claim.
> People, closures is effectively just function using global vars, alright?
Not allright. Wrong.
Global variables have indefinite duration and global accessibility.
Local variables have dynamic duration and local (private) accessibility.
Fluid bindings have dynamic duration and global accessibility.
Own/static variables have indefinite duration and local (private) accessibility.
No two of those are the same. You are confusing global and own/static variables!!
Closures are just like own/static variables, except the private
accessiblity is potentially shared among more than one function or
other block of code that was defined/generated within the single
lexical scope where the closure(s) were produced.
> You want functions to share env? create a naming scheme like
> _contextA_var1, _contextA_var2, ... then functions can share
> _contextA_* vars.
That's practical only if (1) somebody sets up a system of names
whereby each programmer has his/her own private domain within that
system and each programmer sets up his/her own private sub-domains
within that system, such that never are any two domains or
sub-domains in conflict, and (2) programmers are very very careful
to follow the convention very strictly and never step on each
other's names, and (3) all such names are statically generated in
source code. There is no practical way to generate an unlimited set
of such names automatically from a closure-generating factory,
whereas true closures as implemented in Common Lisp are trivial to
generate in unlimited quantity from a factory method.
C++ gets by with such mangled names being passed to the loader
because all such names are generated automatically, and even so
there are only a fixed set of such names defined at compile time
based on a fixed number of symbols directly appearing in source
code within each of a fixed number of programmer-specified
namespaces. That mechanism doesn't work for generating an unlimited
number of new mangled names at runtime, especially when running an
unlimited number of multiple threads that all share a single common
global naming space.
Now there *is* one thing to say for mangled global names, whether
mangled by ordinary prefixes or suffixes as you suggest (and as C++
uses), or by package prefixes: With prefixes/suffixes, the various
functions that share the global variable don't have to be defined
all at the same time, and can be re-defined individually at any
time without breaking the sharing. By comparison a group of lexical
closures must all be defined in a single lexical context, and
re-defining just one of them without the others doesn't work.
But just because both mangled global names and lexical closures are
useful, doesn't mean they are the same thing, as you claim.
> In this way, you have closures, or what closures is supposed to
> achieve in a program, in just about any language.
No, you don't. IMO you are mistaken.
Here's some code in Common Lisp, definition of a closure-factory:
(defun make-closures ()
(let ((x 42))
(list (function (lambda (newx) (setq x newx)))
(function (lambda () x))
)))
Each time you call it, it returns an list of two anonymous
functions, a setter with one arg and a getter with zero args, which
share a private static variable.
You can call it ten thousand times without trouble:
(setq closures (loop for ix from 1 to 10000 collect (make-closures)))
Next, a demo they really work:
(funcall (cadr (nth 5 closures))) ;returns 42
(funcall (cadr (nth 9 closures))) ;returns 42
(funcall (car (nth 9 closures)) 7)
(funcall (cadr (nth 5 closures))) ;returns 42
(funcall (cadr (nth 9 closures))) ;returns 7
Please show code written in C which can do something equivalent at runtime.
Feel free to write the closures into an array instead of a linked list
if that's easier for the purpose of a demo.
> i hijacked the thread to discuss the concept of closure itself in general.
It would be better if you hijack a thread on a topic you actually understand.
> The Kent Pitman fella is a pest.
No, he's a really bright guy, with lots of good insight. I
sometimes disagree with him, because he overlooked something which
I saw, but more often he enlightens me about something I hadn't
realized before he pointed it out.
P� Mon, 05 May 2008 09:06:50 +0200, skrev Kent M Pitman
<······@nhplace.com>:
> I couldn't figure out what the __ stuff was about. It might have been
> a restatement of the *...* idea. Or it might have been saying that a
> closure was only ever used like:
Well __variable is a technique in Python to make class variables (appear)
hidden.
So he might see a closure as equivalent to a class declaration of a
singleton pattern which makes all attributes private.
--------------
John Thingstad
In article <·············@nhplace.com>,
Kent M Pitman <······@nhplace.com> wrote:
> Ken Tilton <···········@optonline.net> writes:
>
> > George Neuner wrote:
> > > Conceptually, closures create a parameterized instance of a function
> > > by capturing the values of the function's free variables.
> >
> > Not sure this matters, but it is not just the values being captured,
> > it is the variables themselves, for I can assign to them and might
> > share them with other closures.
>
> The point you make is valid, but I'm not sure if it matters either,
> but mostly only because Xah's writing is just so hard to read that
> it's hard to tell WHAT is relevant.
In this case he gave an explanation attempt for closures which
was going in the wrong direction. Trying to explain closures
and mentioning global variables (and a naming scheme) is not
a good idea.
What's useful is that he wrote down his idea what a closure
is. It is a start to discuss whether this particular mental model
is useful or not (or if it is not clearly enough defined to
talk about it). That's why I tried to answer his post. I also
try to 'drag' the discussion from the fuzzy to real code.
Programming concepts are learned differently by different
people - some have the ability to learn abstract concepts,
other need to see code, others need to write that code and
see how it works, again other people will need to see a picture
(I mean a picture that visualizes the concept ;-) ), ...
> It saddens me actually, because it sounds like he actually thinks
> about a bunch of issues, and has a lot of energy that is frittered
> away in unproductive fashion. I think it's very hard for people to
> agree with him when they can't tell what he's saying--at least, I
> can't. I think he sometimes covers for less strong English
> composition skills by smokescreens built of personality flair, but
> he'd benefit from some honest self-reflection on whether confronting
> the communication problem more directly wouldn't help him. I don't
> think people would mind talking to him as much if he were less
> flippant about the fact that he's just plain unintelligible a lot, and
> less willing to blame that on other people.
It's not even that I don't agree with all technical things he says.
Even when it is a unpopular message among hackers. For example
I agree that many parts of Emacs are a total usability nightmare.
Fixing keybings would be on my list to fix Emacs (that's
one reason I prefer other Lisp environments, since they often
have (slightly) better/simpler keybindings and interaction mechanisms).
(Lately I was using a very loud and noisy train (the inner doors
were defect). I can use that train and I did because it was still the
fastest way to get home - but it was sure no pleasure. Emacs
is like that, sometimes.)
> In the end, people fail to agree with him, and he mistakes that for
> them disagreeing with him, which is a subtle wording difference, but
> not at all the same thing in practice. And he often appears sure that
> what he MEANS is right, which it might be, for all I can tell. If he
> can't express it well enough to tell, though, it's hard to go much
> farther.
Usually I respond sometimes, when he has some interesting
technical content and it is posted to a relevant newsgroup.
The technical content has not to be correct - it just should
be possible to discuss it. I have my share of wrong (false, not
precise, vague, misleading) stuff posted to comp.lang.lisp, too.
But there are a lot of readers who will catch that and provide
help to correct me (and others). That's part of the posting
experience of comp.lang.lisp - there is a lot of community
knowledge/knowhow - more than a single person has. One of the
first things to learn is that others are a) not stupid and
know quite a lot and b) everybody cooks with water. ;-)
> I will say that many years back, I was talking to Bob Kerns (RWK) when
> we were both working at Symbolics [he and I also worked together at
> MIT and he taught me a great deal about Lisp in my formative years]
> and the topic of the day was a function called dw:accept-2 or
> something like that, I'm not sure I'm remembering the name right... it
> was part of the internals of the accept substrate of Dynamic
> Windows. He had identified it as the largest single function
> definition in Symbolics Genera. It had clearly gotten out of hand.
> He said to me that if he had it to do over again, he'd have written it
> as a flavor [i.e., a "class" in CLOS terminology; DW was written in
> Zetalisp, which was based on Flavors--probably New Flavors by the time
> of this discussion, but it was the same basic idea]. This took me
> aback because I had never clearly understood that a closure was really
> just a vague kind of anonymous, opaque class. Probably I should have
> noticed this ages before, since I had at that point been programming
> in CL for 10 years or so, but I hadn't ever really thought about it in
> such concrete terms. I understood instantly what he was saying,
> though, and it was quite an epiphany. It would never have occurred to
> me to rewrite something involving closures as something involving
> flavors/classes, but it seemed obviously right when he mentioned it.
I don't like closures as a way to create datastructures. I know
that one can use closures to get near an object system, but
I don't think that's a good idea.
If I see this:
(defun make-point (x y)
(lambda (message)
...))
or similar things, I really prefer a plain object system (like CLOS).
There is usually no way to differentiate
different closures (which is a point? which is a line?).
A CLOS object is self identifying and I have standard ways to
associate functions with different types of objects. It
makes debugging easier. In the debugger I see a bunch of
objects and I can see what is an instance of a point and
what is an instance of a class. Closures don't have this property
in the usual Lisp implementation.
But there are uses of closures that I would not
want to be replaced by classes/methods/objects:
(defun ...
(let ((explanation ... ))
...
(make-button :action
(lambda (button)
(do-something button explanation more-magic ... )))
))
Passing down (or up) logic (functions) is useful. Then often
I don't want to assemble all the arguments into a data structure,
but I'm happy that the environment will hold all necessary
variables and their values.
--
http://lispm.dyndns.org/
On 05 May 2008 03:06:50 -0400, Kent M Pitman <······@nhplace.com>
wrote:
>Ken Tilton <···········@optonline.net> writes:
>
>> George Neuner wrote:
>> > Conceptually, closures create a parameterized instance of a function
>> > by capturing the values of the function's free variables.
>>
>> Not sure this matters, but it is not just the values being captured,
>> it is the variables themselves, for I can assign to them and might
>> share them with other closures.
>
>The point you make is valid, but I'm not sure if it matters either,
>but mostly only because Xah's writing is just so hard to read that
>it's hard to tell WHAT is relevant.
>
>It saddens me actually, because it sounds like he actually thinks
>about a bunch of issues, and has a lot of energy that is frittered
>away in unproductive fashion. I think it's very hard for people to
>agree with him when they can't tell what he's saying--at least, I
>can't. I think he sometimes covers for less strong English
>composition skills by smokescreens built of personality flair, but
>he'd benefit from some honest self-reflection on whether confronting
>the communication problem more directly wouldn't help him. I don't
>think people would mind talking to him as much if he were less
>flippant about the fact that he's just plain unintelligible a lot, and
>less willing to blame that on other people.
>
>In the end, people fail to agree with him, and he mistakes that for
>them disagreeing with him, which is a subtle wording difference, but
>not at all the same thing in practice. And he often appears sure that
>what he MEANS is right, which it might be, for all I can tell. If he
>can't express it well enough to tell, though, it's hard to go much
>farther.
I agree. My impression is that Xah is very intelligent. It seems
that he is largely self educated - which I normally consider a plus
provided the learning is sufficiently comprehensive. I generally like
people who love to learn. But being intelligent does not mean that he
has, in his own words, "penetrating insight" into whatever he happens
to be thinking about.
Glancing through his web page, it seems to me that he is struggling to
understand many CS concepts and is annoyed that he is finding it
difficult. He appears to have an almost pathological hatred of jargon
and to be convinced that jargon is meant to exclude people from the
club rather than to efficiently convey ideas.
I could be completely wrong in my impressions, but Xah's language is
sometimes unclear and I am left to guess whether he really understands
what he is talking about.
>To the point in this thread, he's made some remarks about global
>variables that may be reasoned or may not, but that are certainly not
>clearly enough presented to know what in fact he is saying. Then he
>makes fun of and offers active annoyance at people who've gone out of
>their way to engage him rather than dismiss him, trying to ferret out
>what he might be saying.
>
>His remarks on closures vs object-oriented systems might be general
>confusion about what happens presently, or might just be speaking
>abstractly about concepts, and in the latter situation, might or might
>not be reasonable observations. It's just hard to tell.
It is obvious that he has put some thought into the subject, and now
that he's clarified earlier remarks, it's also clear that he has a
rudimentary understanding of the concept - albeit from a theoretical
point of view rather than a practical one.
But it is also seems that he lacks sufficient understanding of
programming semantics to fully appreciate why his simple mental model
isn't workable.
>To Kenny's comment above, the relevance seems to be that
> (defun foo (x) y)
>means more than
> (subst <some-value> 'y '(defun foo (x) y))
>but indeed means that should y be given a new value through program
>execution, foo will see that new value. I'm pretty sure that Xah as
>much as said this.
Kenny was actually replying to me [George] because I said "value"
instead of the technically correct "binding". That particular detail
though was irrelevant to the point I was making about parameterizing
functions.
>I couldn't figure out what the __ stuff was about. It might have been
>a restatement of the *...* idea. Or it might have been saying that a
>closure was only ever used like:
> (defun foo (y) (setq x y))
> (defun bar () x)
> (list (foo 3) (bar) (foo 4) (bar))
> => (3 3 4 4)
>and that globals would live in __x and that other variables would be
>created locally, as if in the FOO definition above, the x would be created
>locally to FOO, not globally, because it had no special marker saying he
>wanted the global variable, as if it meant
> (defun foo (y)
> (let ((x y))
> x))
>but then again... he might not have meant that. His writing doesn't allow
>me to tell.
>
>It's an open question whether he can tell whether
> (defun foo (x) (lambda () x))
>gives a function where the x storage location is new each time foo is
>called, because at least one reading of his writing is that he thinks
>the free x in (lambda () x) might somehow [as a closure variable] refer
>to some __x secret global place that variables get put. This would be kind
>of like a weird gosub kind of thing I think I've seen in some old BASIC
>variants where function arguments weren't really "bound" but were rather
>names of global variables to set on entry to the function, so that
>defining
> (defun foo (x) (+ x 3))
> (defun bar () (foo 4))
>and then calling
> (bar)
>was really the same as writing:
> (defun foo () (+ __x 3))
> (defun bar () (setq __x 4) (foo))
> (bar)
>I don't think this is what Xah means, mostly because I think he's
>smarter than to think this. But his wording is vague enough that I
>think it would support some odd readings in this area. And under this
>reading, he'd be missing the point that (defun foo (x) (lambda () x))
>means that (foo 3) and (foo 3) actually return closures over a different
>x, not over a common x.
I got the gist of it - pseudo-privacy using a naming convention to
segment the global variable space. Very familiar from my days of
embedded C programming.
However, my (maybe wrong) impression was that he was thinking along
the lines of providing static locals as in C and did not realize that
a) multiple closures can share a source function,
b) each closure is a unique parameterization instance of the
source function, and
c) that the private variables need to be per closure rather
than per source function.
From his latest post, it seems like he maybe has realized some of
this. It's unclear to me whether he actually understood it from the
beginning.
>I will say that many years back, I was talking to Bob Kerns (RWK) when
>we were both working at Symbolics [he and I also worked together at
>MIT and he taught me a great deal about Lisp in my formative years]
>and the topic of the day was a function called dw:accept-2 or
>something like that, I'm not sure I'm remembering the name right... it
>was part of the internals of the accept substrate of Dynamic
>Windows. He had identified it as the largest single function
>definition in Symbolics Genera. It had clearly gotten out of hand.
>He said to me that if he had it to do over again, he'd have written it
>as a flavor [i.e., a "class" in CLOS terminology; DW was written in
>Zetalisp, which was based on Flavors--probably New Flavors by the time
>of this discussion, but it was the same basic idea]. This took me
>aback because I had never clearly understood that a closure was really
>just a vague kind of anonymous, opaque class. Probably I should have
>noticed this ages before, since I had at that point been programming
>in CL for 10 years or so, but I hadn't ever really thought about it in
>such concrete terms. I understood instantly what he was saying,
>though, and it was quite an epiphany. It would never have occurred to
>me to rewrite something involving closures as something involving
>flavors/classes, but it seemed obviously right when he mentioned it.
>
>Closures offer variables that hold (as Xah seems to be alluding to, if
>I can understand what he's running on about) state. And classes have
>the additional feature that the state is more "out in the open", if
>you will, especially since in CL one can always get in and use
>WITH-SLOTS [as opposed to languages like Java and C# where you can
>find yourself "locked out" of your class if you were not there at time
>of definition and didn't make something public. I had the vaguest
>sense that Xah was using the term "closed" to mean "encapsulated", and
>if you make this relation between closures and classes, then you can
>sort of see the analogy, even though it is syntactically different
>than how Lisp texts usually talk about it. So maybe this is the
>observation that Xah is making. Or maybe it's related. Or maybe not.
>Who can tell? It's a pity.
>
>As a matter of practice, one cannot credit another with being right in
>an academic or technical discussion merely because they have said
>something vague and that vague thing is not inconsistent with an
>epiphany. If one could get such credit, then I would say things like
>"We need to invent a better power supply." and then claim credit for
>solving a major piece of the climate change problem, while meanwhile
>just chiding people all along for not understanding the detail of my
>remark... The credit goes to the first person to describe how to do
>that in a clear manner that can be executed upon unambiguously by more
>than one person working in isolation, not to the first person who says
>something so vague that it merely spans the relevant problem space.
>
>But what's a worse pity is that Xah can't acknowledge others' attempts
>to engage him for what those attempts are--a friendly act. He seems to
>feel compelled to bat back the very people who are doing the most work
>to treat him like a human being. Much more than he sometimes gives
>the impression he's doing for them. I fully expect he'll explain to
>me why I'm a loser for writing this piece, which is intended not to
>make him feel bad, but rather to encourage him to take constructive
>action that would improve his overall ability to interact with the
>community constructively. All of this just my personal opinion, of
>course. Your (and his) mileage may vary. Ah well. At least I tried.
I think we probably could all cut Xah some slack provided he stops the
rude name-calling.
George
--
for email reply remove "/" from address
George Neuner <·········@/comcast.net> writes:
>
> I think we probably could all cut Xah some slack provided he stops the
> rude name-calling.
>
I tend to agree. If he showed some level of willingness to address
responses based on the content of the response rather than just
personally attacking the poster and if he showed some willigness to even
consider that sometimes he may either be wrong, over simplistic or
willing to learn or expand his ideas based on input from others, then
possibly everyone including Xah could benefit in different ways.
Tim
--
tcross (at) rapttech dot com dot au
On Mon, 05 May 2008 00:13:14 -0400, Ken Tilton
<···········@optonline.net> wrote:
>
>
>George Neuner wrote:
>> Conceptually, closures create a parameterized instance of a function
>> by capturing the values of the function's free variables.
>
>Not sure this matters, but it is not just the values being captured, it
>is the variables themselves, for I can assign to them and might share
>them with other closures.
>
>kt
Yes, the bindings are captured. Sorry ... Xah gets me so riled
sometimes that I can hardly see straight. I really should know
better.
George
--
for email reply remove "/" from address
From: Don Geddis
Subject: Re: A question (confusion) about closure
Date:
Message-ID: <87k5i7qss9.fsf@geddis.org>
·······@gmail.com" <······@gmail.com> wrote on Sun, 4 May 2008 :
> If there are 4 lisp programers, most or all of which i think are
> experienced, and all claim that i was wrong, how can i be right?
At the very least, you ought to more seriously consider the possibility
that you are wrong.
> I'm guessing my problem has to do with my personality. A normal person,
> would probably just discuss the issue in earnest. Like, we all human
> beings, some knows some areas better, and we all make mistakes. A
> discussion can just carry on in its course, and everyone can just learn
> something or simply enjoy the conversation. But Noooo! I can't be like
> that.
That does sound like a problem with your personality, just as you suspected.
Perhaps you'd make more progress if you'd work on this particular problem.
> Still, it troubles me deeply, how could a patently simple explanation, a
> simple concept, a penetrating view, be not clearly grasped by a gaggle of
> lispers? In this thread, there are 15 messages. Not one reply, seems to
> indicate that what i said is correct. Almost half of them actually pointed
> out that i was incorrect, and even unhelpful. I'm greatly troubled by
> this.
If it happened that you _were_ wrong, what kind of evidence do you think
you might see?
I'm curious why you don't at least think about the case where you are not
correct. Might that explain all the reactions you're getting?
> i'm rather quite surprised how my exposition of the closure concept
> turn up so many messages, many claiming it being even unhelpful or
> useless.
If your theories of the world are constantly surprised by actual observations
of that world, at some point you need to consider that perhaps your theories
are in error.
After all, the whole point of a theory is to make what happens later
predictable, not surprising.
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
Christian: One who believes that the New Testament is a divinely inspired book
admirably suited to the spiritual needs of his neighbor. One who follows the
teachings of Christ in so far as they are not inconsistent with a life of sin.
-- Ambrose Bierce, The Devil's Dictionary
Don Geddis <···@geddis.org> writes:
> ·······@gmail.com" <······@gmail.com> wrote on Sun, 4 May 2008 :
>> If there are 4 lisp programers, most or all of which i think are
>> experienced, and all claim that i was wrong, how can i be right?
>
> At the very least, you ought to more seriously consider the possibility
> that you are wrong.
>
>> I'm guessing my problem has to do with my personality. A normal person,
>> would probably just discuss the issue in earnest. Like, we all human
>> beings, some knows some areas better, and we all make mistakes. A
>> discussion can just carry on in its course, and everyone can just learn
>> something or simply enjoy the conversation. But Noooo! I can't be like
>> that.
>
> That does sound like a problem with your personality, just as you suspected.
>
> Perhaps you'd make more progress if you'd work on this particular problem.
>
>> Still, it troubles me deeply, how could a patently simple explanation, a
>> simple concept, a penetrating view, be not clearly grasped by a gaggle of
>> lispers? In this thread, there are 15 messages. Not one reply, seems to
>> indicate that what i said is correct. Almost half of them actually pointed
>> out that i was incorrect, and even unhelpful. I'm greatly troubled by
>> this.
>
> If it happened that you _were_ wrong, what kind of evidence do you think
> you might see?
>
> I'm curious why you don't at least think about the case where you are not
> correct. Might that explain all the reactions you're getting?
>
>> i'm rather quite surprised how my exposition of the closure concept
>> turn up so many messages, many claiming it being even unhelpful or
>> useless.
>
> If your theories of the world are constantly surprised by actual observations
> of that world, at some point you need to consider that perhaps your theories
> are in error.
>
> After all, the whole point of a theory is to make what happens later
> predictable, not surprising.
>
I've re-read what Xah wrote and in addition to what you have pointed out
I would add
* Xah's skills with respect to writing are very poor. Reading followups
to his posts and doing a bit of 'reading between the lines' often
provides additional information that make his initial
claims/rants/explinations a little easier to
understand. Unfortunately, despite suggestions from many that he work
on this skill in order to get his message across more effectively, it
does not appear he can handle any form of criticism without becoming
totally defensive even when that criticism is presented in an
obviously well meaning and patient way. See Kent's post in this thread
and Xah's response.
* From reading a number of his posts, it seems clear that Xah hopes to
provide some level of demystification of many technical concepts. This
is an admirable goal, but one which is undermined by his poor
communication skills. However, he often makes the mistake of over
simplification. This immediately makes others respond with claims that
he is wrong. In reality, I suspect that he is not strictly wrong, but
rather presents an overly simplistic explination that unfortunately is
potentially misleading. For example, in this current thread on
closures, I get the impression that Zah is providing an explination
via an over simplistic analagy that essentially says that a closure is
a technique to create a function that has its own private storage that
can maintain a sort of function state. His use of the term global
variable has muddied the waters and clouded the message I suspect he
was trying to get across. His claim he can do closures using global
variables is misleading as I suspect what he really means is that you
could simulate the same properties using such variables. His point
could possibly have been less contentious if he had concentrated on
using an analagy closer to that of objects. His references to using
global variables glosses over the limitations and complexities that
would be involved in getting only the most basic properties of a
closure in his simulated version. However, the most misleading aspect
of his explination is that it effectively makes closures seem like
nothing but a 'cute' programming trick and is likely to make some feel
that it has no relevance and no practicle application in the real
world.
* Xah's claims that no other languages other than CL use closures is
also incorrect and shows that while he may have some grasp of
theoretical mathematical concepts, he has little understanding of many
of the languages he tries to speak about with authority. For example,
the first place I came across closures was in perl and in a real-world
application. This was one of the languages that he claimed didn't use
closures.
* I suspect Xah suffers from some form of paranoia or related
personality disorder and can't help but see any level of criticism as
a personal attack. He seems unable or at least unwilling to actually
consider that he may actually cause the 'attacks' he recieves and is
unable to recognise his own contribution to the situation. The whole
rest of the world is wrong and he is the only one who is right. It
reminds me of a programmer I once worked with. He was quite a good
programmer and quite intelligent, but was never able to recognise his
own role in creating bugs. Whenever he was having trouble finding a
bug in a bit of code, he would immediately start suspecting bugs in
the language, OS or a virus. I'd point out how unlikely it was for him
to have tripped over a bug in the language (At the time, we were
working in C) and that it was almost certainly a bug in his code. He
refused to believe it - logged bug reports with the compiler vendor,
got the sys admins to check for viruses and blamed all the libraries
we were using. In the end, it turned out to be a bit of his code that
was attempting to access memory via a pointer that had already been
passed to free(). Apart from this occuring when viruses were still
quite new and rare and apart from the fact that this would have to be
one of the most common bugs you encounter in C, the real issue was
that he simply couldn't see his own part in the equation - his code
was perfect and it had to be something else not him. Xah is like that
programmer.
* I've noticed that Xah posts on a wide variety of topics and seems to
produce a huge amount of output. Despite the fact that most of what I
have read of his work could be reduced by half and be a lot clearer
and more succinct if only he tried to refine his style and applied
some rigor to his editing, I find that with only a few exceptions, his
analysis seems shallow and lacking in any evidence of real depth of
knowledge and understanding. It is possible that this is due to his
poor expressive skills, but i suspect that he is reasonably
intelligent and has a broad but shallow grasp of many topics. This in
itself is fine, but anyone who really wants to explain difficult or
even not so difficult topics really needs to have a very solid
understanding before attempting to explain it to others who do not.
Anyway, I'll leave it at that. In conclusion, I suspect Xah isn't quite
as incorrect as most of us initially thought, but as Kent points out,
his style of expression makes it very difficult to know for
certain. This combined with a tendency to over simplify tends to get the
wrong response and probably makes him worse and in the end it all just
ends up with the same pointless threads going around in a circle.
Tim
P.S. Xah, if you read this, save yourself the effort. I know you want to
respond and tell me how much you hate me and how I should go back to
school/college/homework and that you are perfect and misunderstood blah blah
blah. Its predictable and boring. Lets just assume you have responded
and insults from a faceless paranoid in another country has scarred me
for life. I'll organise some councelling tomorrow to help me get over
it.
BTW: You are wrong in your assumption regarding my age and what I do. I
finished school before you were even born and have more life behind me
than I have left in front. My first paid job with computers was so long
ago its just a hazy memory of punch cards and a wonderful new aid to
productivity, the tty. (Actually, I've still got a few boxes of punch
cards - I find them very useful for making notes as they fit quite
nicely in your shirt pocket (doubled over that is).
--
tcross (at) rapttech dot com dot au
In article <·················@lion.rapttech.com.au>,
Tim X <····@nospam.dev.null> wrote:
...
...
> reminds me of a programmer I once worked with. He was quite a good
> programmer and quite intelligent, but was never able to recognise his
> own role in creating bugs. Whenever he was having trouble finding a
> bug in a bit of code, he would immediately start suspecting bugs in
> the language, OS or a virus. I'd point out how unlikely it was for him
> to have tripped over a bug in the language (At the time, we were
> working in C) and that it was almost certainly a bug in his code. He
> refused to believe it - logged bug reports with the compiler vendor,
> got the sys admins to check for viruses and blamed all the libraries
> we were using. In the end, it turned out to be a bit of his code that
> was attempting to access memory via a pointer that had already been
> passed to free().
What reaction to the (his) bug when he either discovered it for himself
or had it pointed-out to him by someone else?
Apart from this occuring when viruses were still
> quite new and rare and apart from the fact that this would have to be
> one of the most common bugs you encounter in C, the real issue was
> that he simply couldn't see his own part in the equation - his code
> was perfect and it had to be something else not him.
David
·······@panix.com (David Combs) writes:
> In article <·················@lion.rapttech.com.au>,
> Tim X <····@nospam.dev.null> wrote:
> ...
> ...
>> reminds me of a programmer I once worked with. He was quite a good
>> programmer and quite intelligent, but was never able to recognise his
>> own role in creating bugs. Whenever he was having trouble finding a
>> bug in a bit of code, he would immediately start suspecting bugs in
>> the language, OS or a virus. I'd point out how unlikely it was for him
>> to have tripped over a bug in the language (At the time, we were
>> working in C) and that it was almost certainly a bug in his code. He
>> refused to believe it - logged bug reports with the compiler vendor,
>> got the sys admins to check for viruses and blamed all the libraries
>> we were using. In the end, it turned out to be a bit of his code that
>> was attempting to access memory via a pointer that had already been
>> passed to free().
>
> What reaction to the (his) bug when he either discovered it for himself
> or had it pointed-out to him by someone else?
>
No real reaction - he just got a bit quiet. Initially, I thought it was
because he realised he had been misguided and had learnt a
lesson. Unfortunately not, only a couple of weeks later, he was doing
something similar again - a different bug this time, but again, he
looked at everything else before he was forced to really consider it was
his bug/error.
Odd thing was that in most other things, he seemed very sharp and quite
smart. He picked up ideas quickly, had a very good grasp of mathematics
and comp sci theory. Even his programming was better than average apart
from his weird inability to consider his own part in any problem
relating to code he was developing.
Unfortunately, after a few months "his resources were freed up in order
to allow him to pursue other opportunities', what use to be called being
fired.
Tim
>
--
tcross (at) rapttech dot com dot au
From: Robert Maas, http://tinyurl.com/uh3t
Subject: Re: A question (confusion) about closure
Date:
Message-ID: <rem-2008may04-004@yahoo.com>
> From: ·······@gmail.com" <······@gmail.com>
> Basically, if your language can define a function, and mai[n]tain a
> permanent internal variable inside, it's closure.
It's actually more than that. Simply having a variable that is
private to a single block but not re-initialized every time the
block is entered, which retains its value from one entry to the
next, was called an "OWN" variable in Algol 60:
<http://www.masswerk.at/algol60/modified_report.htm#5>
but is now called a "Static local variable" in WikiPedia:
<http://en.wikipedia.org/wiki/Local_variable#Static_local_variables>
But in a closure, the *same* private variable ("binding" in Lisp
jargon) can be *shared* between two or more blocks/functions. Thus
a closure allows *shared* own/static variables, so that the
*shared* latest-value is preserved across entries to *either* block
and accessible equally from each:
(let ((x 42))
(defun setx (newx) (setq x newx))
(defun getx () x)
"Done: Defined SETX with one arg and GETX with no args")
It works with first-class anonymous functions just the same:
(let ((x 42))
(values (function (lambda (newx) (setq x newx)))
(function (lambda () x))))
And of course you can mix the two if you want.
(let ((x 42))
(defun setx (newx) (setq x newx))
(function (lambda () x)))
Note that technically the name is "lexical closure" for the
mechanism used in Lisp, where we use a lexical binding such as LET
or LAMBDA or even PROG to temporarily create an environment with
one or more lexical variables temporarily created, in which several
functions can be created/defined, each sharing that temporary
environment, hence all of them sharing those particular lexical
bindings, except that because of the functions closing over
variables in that lexical environment, the bindings become
permanent in the sense that the lexical-binding environment is
preserved indefinitely, to be used by those defined/created
functions as long as those functions continue to exist. (Or just
define/create ONE function in that lexical environment, which
reduces to OWN/STATIC variables from Algol/WikiPedia.)
For a koan-like explanation: A set of one or more "lexical
closure(s)" is/are a set of functions defined inside of a lexical
context of bindings, thereby achieving the effect of those bindings
becoming privately shared own/static variables.
> Note: The terminology =E2=80=9CClosure=E2=80=9D is actually a very
> bad terminology. It spreads endless confusion and non-understanding.
I agree. The correct Lexical Closure also leads to some confusion
among people who haven't read a decent explanation yet. I hope my
explanations above are close to what would be needed to un-confuse
newbies. Maybe somebody can re-word it to flow easier? My wording
is somewhat clumsy but maybe Kent can clean it up to be *perfect*?
One really neat thing about Common Lisp's lexical closures,
compared to C++'s and Java's classes with static variables, is that
in CL our lexical environment doesn't require a name (the name of
the C++ or Java *class*) and doesn't need to be defined in a
separate file whose name matches the name of the *class*.
From: Robert Maas, http://tinyurl.com/uh3t
Subject: Nigerian spammer harvesting from these newsgroups (was: A question (confusion) about closure)
Date:
Message-ID: <rem-2008may28-001@yahoo.com>
> From: ·················@SpamGourmet.Com (Robert Maas, http://tinyurl.com/uh3t)
> Newsgroups: comp.lang.lisp,comp.lang.functional
I posted only four articles under this address, but one of them got
harvested by a Nigerian spammer. As a result, I've shut down this
address so that I won't get any more spam via this address. Any
e-mail sent to this address will be accepted by the server then
just discarded without any non-delivery notice. That's why I'm
posting this warning, just in case somebody saw any of my four
articles just now and wants to reply to me privately If anybody
wants to send private e-mail to me regarding anything I've posted,
you'll have to look around to find some other variant address that
I haven't yet disabled, or go to my Web site and click on "Contact me".
Here's part of the Nigerian spam I got just today:
Received: from mail.zu.edu.eg ([193.227.29.11]) by
gourmet.spamgourmet.com (8.13.8/8.13.7) with ESMTP id m4S5uXr0002827
for <·················@spamgourmet.com>; Wed, 28 May 2008 05:56:34 GMT
RIPE WHOIS shows that IP number belongs to:
inetnum: 193.227.0.0 - 193.227.31.255
descr: Egyptian Universities Network
person: Gamal Mohamed Aly
address: FRCU Computer Center
address: Supereme Council of University
address: Giza
address: Egypt.
phone: +2 02 5735405
phone: +2 02 5738530
fax-no: +2 02 5728174
e-mail: ······@frcu.eun.eg
person: Nashwa Abdel-Baki
address: EUN Computer Center
address: Supreme Council of Universities
address: Cairo University Campus
address: POBOX 268 Orman
address: Giza
address: Egypt
phone: +2 02 5735405
phone: +2 02 5738530
phone: +2 02 7742344
phone: +2 02 7742345
phone: +2 02 7742346
fax-no: +2 02 7742347
e-mail: ······@MAILER.eun.eg
If there is any spam-hater located in Egypt and seeing this report,
please investigate the legal consequences of a university allowing
its local network to be used for international harassment and fraud.
I'd like to see the person responsible for security on that localnet
fired and the president of the university held responsible for
hiring a new localnet-security expert who will prevent recurrance.
Subject: URGENT. SIR/MA
To: ·················@spamgourmet.com
From: "STEVEN PERKMAN" <··············@hotmail.com>
Obviously that address is forged, right? If there is any spam-hater
seeing this report who has inside connections at hotmail, please
investigate whether Mr. Perkman has any connection other than being
a victim of forgery via his address having been harvested. I know
from past experience that MicroSoft/HotMail never does anything to
help victims of spam that comes directly from their own IP numbers,
so there's no way they'd be willing to investigate a report of spam
from some other ISP that forges a hotmail address, even if in fact
the hotmail address really is the spammer's dropbox.
I am Dr. STEVEN PERKMAN ,Managing Partner,with Robert Fore
& Associates Law firm, Dubai Branch.Admitted, 1974.
Education: LL.B 1973 Bristol University Practice
Areas: Corporate; Commercial; Oil & Gas,International
Trade; Banking, inheritance law, e.t.c
On behalf of the Trustees and Executor of the Estate
of Late George Brumley, I wish to notify you that late
George Brumley made you one of the beneficiaries of
his estate. He left the sum of Five Million One
Hundred Thousand Dollars (USD$5,100.000.00 )to you.
(... the usual Nigerian pigeon-drop fake-money-laundering scam ...)
http://www.cnn.com/2003/WORLD/africa/07/20/kenya.crash/index.html
(legitimate news story)
The spam offers no way to reply to the spammer to arrange delivery
of fake bankcheque, except the hotmail address, so I'm thinking
that hotmail address really might be owned by the spammer. Too bad
the CAN-SPAM law protects MicroSoft from legal subpoenas regarding
their customers using MicroSoft services to engage in criminal
activity. Too bad MicroSoft has a policy of condoning use of their
servers to support criminal activity, taking full advantage of
their CAN-SPAM immunity. Too bad the citizens of this country are
too cowardly to take on MicroSoft directly by boycotting all their
products and services until MicroSoft starts being part of the
solution instead of part of the problem as they are currently.
I like the Apple commercial: MicroSoft Vista system says:
I've been error free for over a week.
I've been error free for over a week.
I've been error free for over a week.
I've been error free for over a week.
I've been error free for over a week.
I've been error free for over a week.
I've been error free for over a week.
I've been error free for over a week.
I've been error free for over a week.
I've been error free for over a week.
I've been error free for over a week.
I've been error free for over a week.
I've been error free for over a week.
On May 28, 3:41 pm, ·················@spamgourmet.com (Robert Maas,
http://tinyurl.com/uh3t) wrote:
>
> Here's part of the Nigerian spam I got just today:
> Received: from mail.zu.edu.eg ([193.227.29.11]) by
> gourmet.spamgourmet.com (8.13.8/8.13.7) with ESMTP id m4S5uXr0002827
> for <·················@spamgourmet.com>; Wed, 28 May 2008 05:56:34 GMT
> RIPE WHOIS shows that IP number belongs to:
> inetnum: 193.227.0.0 - 193.227.31.255
> descr: Egyptian Universities Network
> person: Gamal Mohamed Aly
> address: FRCU Computer Center
> address: Supereme Council of University
> address: Giza
> address: Egypt.
Nigerian spam....from Egypt. Idiot.
På Fri, 02 May 2008 10:31:18 +0200, skrev Samik <······@gmail.com>:
> Hi,
>
> I have a confusion regarding closure and its definition. As per Paul
> Graham:
>
> When a function refers to a variable defined outside it, it’s called a
> free variable. A function that refers to free lexical variable is
> called a closure.
>
> However as per CLHS a closure or lexical closure is:
>
> lexical closure n. a function that, when invoked on arguments,
> executes the body of a lambda
> expression in the lexical environment that was captured at the time of
> the creation of the lexical closure, augmented by bindings of the
> function's parameters to the corresponding arguments.
>
> lexical environment n. that part of the environment that contains
> bindings whose names have lexical scope. A lexical environment
> contains, among other things: ordinary bindings of variable names to
> values, lexically established bindings of function names to functions,
> macros, symbol macros, blocks, tags, and local declarations (see
> declare).
>
> Can any pro lisper kindly help me?
>
> Thanks,
> Samik
> Blog: http://lispsamik.blogspot.com/
In a nutshell.
(let ((val const))
(defun func (...)
(setf val ...)
...))
Func sees val but outside the scope it doesn't.
The trick is that the lexical environment survives the oldest function
referring to it.
This becomes particularly interesting when returning a anonymous function.
(let ((val const))
(defun func (...)
(setf val ...)
(lambda (...) ...)))
Where lambda too knows val.
For a practical example study study the CL-PPCRE library.
--------------
John Thingstad
Samik <······@gmail.com> writes:
> Hi,
>
> I have a confusion regarding closure and its definition. As per Paul
> Graham:
>
> When a function refers to a variable defined outside it, it's called a
> free variable. A function that refers to free lexical variable is
> called a closure.
>
I'm not clear on what you are asking about. Are your
concerns about Common Lisp or English?
Graham's first sentence clunks. The fault is the use of the
pronoun "it" twice, with different referents. The sentence
should be
When a function refers to a variable defined outside it,
we call the variable a free variable.
One reason that it is important to write is that one learns
how hard it is to express oneself clearly. Armed with this
knowledge one can take a realistic attitude to other authors
writings. Graham was not entirely clear. Diagnose the
problem using the skills one has developed for making ones
own writing clear to others. Work out what he meant and move
on.
The REPL is your friend. Chat with the REPL:
CL-USER> (defparameter *op-list*
(let ((count 0))
(list (lambda()(incf count))
(lambda()(decf count))
(lambda()(setf count 0)))))
*OP-LIST*
CL-USER> (funcall (first *op-list*))
1
CL-USER> (funcall (first *op-list*))
2
CL-USER> (funcall (first *op-list*))
3
CL-USER> (funcall (second *op-list*))
2
CL-USER> (funcall (third *op-list*))
0
CL-USER> (funcall (second *op-list*))
-1
CL-USER> (funcall (second *op-list*))
-2
Notice the use of assignment, directly with setf, and
lurking inside incf
CL-USER> (macroexpand-1 '(incf x))
(LET* ((#:G1626 1) (#:G1625 (+ X #:G1626)))
(SETQ X #:G1625))
The use of assignment is essential.
Your state machine example in your blog post does no
assignment and only accidently appears to work. I found it
very confusing. I'll explain why.
Consider the following state machine; it has two states
S0 (represented as 0) and S1 (represented as 1). Here
is the logic that it performs, if the current state of
the machine is S0 and input is 0 it remains in S0 else
machine goes to state S1. If the current state of the
machine is S1 and input is 0 it changes the state to S0
else it remains in state S1. This machine accepts 1 and
0 as input. Also note that this machine initializes at
state S0.
Here is the code:
(let ((s0 0) (s1 1) (state 0))
(defun input-action(in)
(if (eq state in)
state
(if (eq state s0)
s1
s0))))
(I'm no expert on HTML but I've put the indentation back
in. I think that you need to use the <pre> tag to preserve the leading
white space. Is there another tag that does the job?)
What confused me was trying to reconcile the description
with the code
(let ((s0 0)(s1 1) ....
What pops into my head is that you have two state variables
s0 and s1 and four states.
s0 = 0, s1 = 0
s0 = 0, s1 = 1
s0 = 1, s1 = 0
s0 = 1, s1 = 1
Actually no. You are doing something very different, better
written
(defconstant s0 0)
(defconstant s1 1)
(let ((state 0))
(defun input-action (in) ...)
(defun report () state))
With an extra function, to directly examine the state, you
can see that it doesn't change. The point is covered up
because you are encoding the input as a set of numbers {0,
1} and encoding the states as a set of numbers {0, 1}, and,
oh look, its the same set.
Sometimes you have a particular encoding handed to you, for
example, by the designers of a microprocessor, but this is
rather specialised. In Common Lisp, it is best to use
symbols directly.
CL-USER>
(let ((state 'off))
(declare (type (member on off) state))
(defun input-action (input)
(declare (type (member push nil) input))
(setf state
(case input
(push (case state
(on 'off)
(off 'on)))
((nil) (case state
(on 'on)
(off 'off)))))))
; Converted INPUT-ACTION.
INPUT-ACTION
CL-USER> (dolist (input '(nil nil push nil push push push))
(print (input-action input)))
OFF
OFF
ON
ON
OFF
ON
OFF
NIL
Notice my use of declarations. They are not necessary. If
you were writing real code you would either leave them out
or use a deftype to abbreviate them. However they are better
than comments as decoration for code posted online because
they have a formal meaning.
Notice that CASE clauses are headed by lists of things,
which is just what you want for state machines. A symbol
works as a designator for a list with one item, that
symbol. Which is very convenient, except that NIL is the
empty list and doesn't match anything. You can abbreviate
((push) ...) as (push ...), but you cannot abbreviate ((nil)
...) as (nil ...)
Your example and my example both suffer from the problem of
being too simple. Since they don't really do anything it is
hard for the reader to get the point and see how they do
what they do. The example needs to be more complicated. But
just a tiny bit more complicated, or the complications will
conceal the point. I'm going to drop out at this
point. Writing is hard. Writing requires practise. Please
feel encouraged to write another blog post.
Alan Crowe
Edinburgh
Scotland
On May 2, 1:31 am, Samik <······@gmail.com> wrote:
> Hi,
>
> I have a confusion regarding closure and its definition. As per Paul
> Graham:
>
> When a function refers to a variable defined outside it, it’s called a
> free variable. A function that refers to free lexical variable is
> called a closure.
>
> However as per CLHS a closure or lexical closure is:
>
> lexical closure n. a function that, when invoked on arguments,
> executes the body of a lambda
> expression in the lexical environment that was captured at the time of
> the creation of the lexical closure, augmented by bindings of the
> function's parameters to the corresponding arguments.
>
> lexical environment n. that part of the environment that contains
> bindings whose names have lexical scope. A lexical environment
> contains, among other things: ordinary bindings of variable names to
> values, lexically established bindings of function names to functions,
> macros, symbol macros, blocks, tags, and local declarations (see
> declare).
Hi Samik,
I'm no pro, but Graham's explanation does not square with everything
else I've been learning about closures. The definitions you provided
are correct, but they are difficult to understand for people who are
unfamiliar with the terms they use. The big "aha" moment for me
occurred when I realized the "lexical environment" was a THING. It's
essentially something like an association table that matches symbols
to values.
Think of it this way: in a Lisp without closures, a procedure is
just a procedure. In a lisp with closures, a procedure is data-
structure that has two parts: 1) code that does something, and 2)
something like an association table that captures the state of all the
variables when the function is called. So every time a function is
run in a Lisp with closures, a new lexical environment is
manufactured to go along with it.
When Lispers talk about how closures can be used to implement objects
and object-oriented programming, they are talking about using
techniques to coax the procedure part of the procedure-data-structure
into manipulating the lexical environment part of the procedure-data-
structure.
Edward
Samik <······@gmail.com> writes:
> Hi,
>
> I have a confusion regarding closure and its definition. As per Paul
> Graham:
>
> When a function refers to a variable defined outside it, it’s called a
> free variable. A function that refers to free lexical variable is
> called a closure.
>
> However as per CLHS a closure or lexical closure is:
>
> lexical closure n. a function that, when invoked on arguments,
> executes the body of a lambda
> expression in the lexical environment that was captured at the time of
> the creation of the lexical closure, augmented by bindings of the
> function's parameters to the corresponding arguments.
>
> lexical environment n. that part of the environment that contains
> bindings whose names have lexical scope. A lexical environment
> contains, among other things: ordinary bindings of variable names to
> values, lexically established bindings of function names to functions,
> macros, symbol macros, blocks, tags, and local declarations (see
> declare).
>
> Can any pro lisper kindly help me?
;; John's example:
(let ((val const)) ; local, lexical variable
(defun func (...) ; lexical closure
(setf val ...) ; val is free in func
...))
(defvar *val* 'value) ; global, dynamic variable
(defun gunc (...) ; a closure too!
(setf *val* ...) ; *val* is free in gunc.
...)
Now, technically, in Common Lisp a function whose free variables are
all global, dynamic variables wouldn't be called a closure, since
these variable are not really enclosed in an environment with the
function: they just lie in the global environment, along these
functions, and since it's considered a closed universe, there's no
outside to be considered enclosed. When everybody is something,
there's no point in naming it.
Even a function without free variables could be considered a closure,
if the implementation encloses it in an empty environment, just for
the sake of homogeneity with the other closures. But CL leaves the
implementations free to optimize this case out.
--
__Pascal Bourguignon__
On Fri, 2 May 2008 01:31:18 -0700 (PDT), Samik <······@gmail.com>
wrote:
>Hi,
>
>I have a confusion regarding closure and its definition. As per Paul
>Graham:
>
>When a function refers to a variable defined outside it, it�s called a
>free variable. A function that refers to free lexical variable is
>called a closure.
>
>However as per CLHS a closure or lexical closure is:
>
>lexical closure n. a function that, when invoked on arguments,
>executes the body of a lambda
>expression in the lexical environment that was captured at the time of
>the creation of the lexical closure, augmented by bindings of the
>function's parameters to the corresponding arguments.
>
>lexical environment n. that part of the environment that contains
>bindings whose names have lexical scope. A lexical environment
>contains, among other things: ordinary bindings of variable names to
>values, lexically established bindings of function names to functions,
>macros, symbol macros, blocks, tags, and local declarations (see
>declare).
>
>Can any pro lisper kindly help me?
>
>Thanks,
>Samik
>Blog: http://lispsamik.blogspot.com/
Closures aren't really complicated. There is a technical definition
of closure in terms of bound and free variables, but essentially
closures are about capturing non-local, lexically scoped variables at
the time the function is defined.
I assume you are familiar with lexical scoping. Cribbing John
Thingstad's example:
(let ((val init))
(defun func (...)
(setf val ...)
...))
we see the definition of a function 'func' which references (indeed
modifies) a non-local variable 'val'.
In Lisp (and some other languages), functions are allowed to use
variables which are in scope at the point of definition even if those
same variables are not in scope at the point of execution. This
feature is useful, for example, for preserving private data between
executions of a function.
In John's example, the variable 'val' cannot simply disappear after
'func' is defined - as lexical scoping would imply - because it will
be needed when the function is executed.
To accomplish this, the compiler creates a data structure which
associates the function's code with bindings for the non-local
variables needed by the function. This data structure is known as a
closure. [In reality there are ways to do this that do not actually
create a new data structure. The term "closure" can refer to any
runtime mechanism that associates a function with its non-local
variables.]
Technically, any function definition creates a closure regardless of
whether there are non-local variables involved (thus technically, most
programming languages have closures), but the non-local variable case
is the only interesting one. It also isn't necessary for the function
to modify a non-local variables to preserve it in the closure - that
just guarantees preservation - variables which are only read accessed
also have to be preserved if their values are not atomic.
To everybody who is dissatisfied with this explanation, my intent is
not to be perfectly correct wrt Lisp or indeed any particular language
implementation, but rather to explain the concept in general terms.
Feel free to comment on anything you think is too simplistic.
George
--
for email reply remove "/" from address
On May 2, 4:31 am, Samik <······@gmail.com> wrote:
> Hi,
>
> I have a confusion regarding closure and its definition.
Robert Wilensky's explanation of closures tweaks one's intuitive
understanding of the topic. He does it in his book "Common LISPcraft",
Chapter 12 "Writing More Flexible Functions"
http://www.amazon.com/Common-Lispcraft-Robert-Wilensky/dp/0393955443
I think that chapter is well worth the reading for an introduction to
closures. The relevant section is only 6 pages.
agt