Prev: You want abbreviations? You can't handle abbreviations!
Next: Hot Shop Audemars Piguet Royal Oak Watches - Audemars Piguet Minimum Price
From: Ken Tilton on 5 May 2008 00:13


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 on 5 May 2008 03:06
Ken Tilton <kennytilton(a)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.
From: viper-2 on 6 May 2008 14:32
On May 6, 12:14 pm, Didier Verna <did...(a)xemacs.org> wrote:
> viper-2 <visio...(a)mail.infochan.com> wrote:
> > On May 6, 3:57 am, Didier Verna <did...(a)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
From: John Thingstad on 5 May 2008 03:30
P� Mon, 05 May 2008 09:06:50 +0200, skrev Kent M Pitman
<pitman(a)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
From: Rainer Joswig on 5 May 2008 04:08
In article <utzhdb56d.fsf(a)nhplace.com>,
Kent M Pitman <pitman(a)nhplace.com> wrote:

> Ken Tilton <kennytilton(a)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/
 |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8
Prev: You want abbreviations? You can't handle abbreviations!
Next: Hot Shop Audemars Piguet Royal Oak Watches - Audemars Piguet Minimum Price